Closed jaywryan closed 2 years ago
Hi Ilkka,
right now I have a problem with the creation of a rootless container cause of the systemd file as well. You can see the code that is in the role right now below and it will lead to an error as my rootless user is supposed to create a file that should be owned by root. Either we let the rootless user create the file, but root won't be the owner, or we remove the become statements.
owner: root group: root mode: 0644 become: true become_user: "{{ container_run_as_user }}"
True, the become should be root.
So what do you guys think? Is it good idea at all that root owns the files, and user has no way to alter them? In my use case, the user is service user who normally doesn't log in ever. However while debugging stuff one needs to login twice, once as a service user and once as a sudo user to be able to modify the files and restart pods.
The plus side in my eyes was that even if for some weird reason someone got in as the service user, they could not modify the systemd file as an extra layer of security.
I like the idea of additional security by not being able to change the files without root access. My account for rootless podman is also a service user that can only be accessed via su.
What I was wondering is if it would be even better to add the functionality to write the systemd services system wide (/etc/systemd/system
or /usr/local/lib/systemd/system
and make use of the User and Group parameters for the service. That way we run the services with a rootless user and no one will be able to fiddle with the services in any way without root access. Of course this could also be the default, but this would be a breaking change for older deploys.
[Service]
User={{ podman_rootless_user }}
Group={{ podman_rootless_group }}
It doesn't work that way. That's how it was originally, but I had to change it to user home dir systemd dirs. I don't really know why. It has something to do with dbus I suppose. The same as you can't run podman if you just sudo to user.
I see, that is interesting. I thought I tried it already and it had been working. I think maybe it might be working as we enable lingering for the account. I will check again to verify if this is the case or not.
I just tried it out like promised. I did the setup by hand now to be sure that nothing was created in a way not expected. I used podman to pull the image from the podman rootless account and I configured the service, example for kavita in /etc/systemd/system. And it worked without any problems. This might work now as we enable linger for the user, I am not sure as I didn't test that, but the container is working.
[Unit] Description=kavita Podman Container After=network.target
[Service] Type=simple TimeoutStartSec=15 User=podman-rootless Group=podman-rootless ExecStartPre=-/usr/bin/podman stop -t 15 kavita ExecStartPre=-/usr/bin/podman rm -f kavita ExecStartPre=-/usr/bin/rm -f %T/%n-pid %T/%n-cid
ExecStart=/usr/bin/podman run --name kavita \
--rm --label "io.containers.autoupdate=registry" -e TZ=Europe/Stockholm -v /home/podman-rootless/kavita/config:/kavita/config -v /home/podman-rootless/kavita/books:/manga -p 5000:5000 \
--conmon-pidfile %T/%n-pid --cidfile %T/%n-cid \
kizaing/kavita:latest
ExecStop=/usr/bin/sh -c "/usr/bin/podman stop -t "15" cat %T/%n-cid
"
ExecStop=/usr/bin/sh -c "/usr/bin/podman rm -f cat %T/%n-cid
"
Restart=on-failure
RestartSec=30
KillMode=mixed
PIDFile=%T/%n-pid
Environment=PODMAN_SYSTEMD_UNIT=%n
[Install] WantedBy=default.target
And it is normally visible in user session with podman ps? Nice, intereating to know, thanks for testing.
And it is normally visible in user session with podman ps?
Yes exactly.
Seems to me the #59 fixed this, I close this. If not, please re-open.
fix: containers not pulled when non-root fix: service files should be owned by service owner
Please advise. I made these changes to get the containers to pull in my environment. It seems a change was made and containers were not being pulled when running in rootless mode. I also made a small change where the systemd file will be owned by the rootless user in rootless mode.