podman-container-systemd
podman-container-systemd copied to clipboard
Rootless container deployment fails when placing systemd unit file
I am trying to deploy a rootless container and have encountered the following issue during the deployment:
TASK [ikke_t.podman_container_systemd : create systemd service file for container: jenkins] *****************************
fatal: [localhost]: FAILED! => {"changed": false, "checksum": "630539e436b8ae828bcba4e209bcb97e0879d356", "gid": 1000, "group": "bblasco", "mode": "0644", "msg": "chown failed: [Errno 1] Operation not permitted: b'/home/bblasco/.config/systemd/user/jenkins-container-pod-bblasco.service'", "owner": "bblasco", "path": "/home/bblasco/.config/systemd/user/jenkins-container-pod-bblasco.service", "secontext": "unconfined_u:object_r:systemd_unit_file_t:s0", "size": 826, "state": "file", "uid": 1000}
It looks like the task is hard coded to become the container_run_as_user
and then attempts to change the ownership of the file to root:root, which is incorrect for a rootless container. See line 198 here: https://github.com/ikke-t/podman-container-systemd/blob/master/tasks/main.yml
- name: "create systemd service file for container: {{ container_name }}"
template:
src: systemd-service-single.j2
dest: "{{ service_files_dir }}/{{ service_name }}"
owner: root
group: root
mode: 0644
become: true
become_user: "{{ container_run_as_user }}"
I have been playing around with changing the owner and group to the relevant variables but the playbook still bombs out here. Is there a problem with switching to container_run_as_user
and the underlying chown/chgrp?
Info about my system
- Fedora 35
- ansible 2.9.27
- podman-container-systemd 1.30 from Ansible Galaxy
- Playbook in use can be found here: https://github.com/benblasco/ansible-podman-examples/blob/ben-local-use/run-container-jenkins-podman.yml
I left the fike ownership to root at the time when I created these. I thought it would be better the service user is not able to modify the files. I thought there is no need for such, so security wise why should it be owned by such service user.
But this pops up every now and then, so perhaps it would be better to make it optional. If you are willing, please create a PR with an option for the service user to own the config files.
In such a way that the file owner would then alternatively be the container user or root.
Either way the playbook fails, so is there a fundamental error in the playbook regardless of preferred permissions?
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Ilkka Tengvall @.> Sent: Monday, August 8, 2022 3:34:02 PM To: ikke-t/podman-container-systemd @.> Cc: benblasco @.>; Author @.> Subject: Re: [ikke-t/podman-container-systemd] Rootless container deployment fails when placing systemd unit file (Issue #58)
I left the fike ownership to root at the time when I created these. I thought it would be better the service user is not able to modify the files. I thought there is no need for such, so security wise why should it be owned by such service user.
But this pops up every now and then, so perhaps it would be better to make it optional. If you are willing, please create a PR with an option for the service user to own the config files.
In such a way that the file owner would then alternatively be the container user or root.
— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fikke-t%2Fpodman-container-systemd%2Fissues%2F58%23issuecomment-1207686199&data=05%7C01%7C%7C685eb45b207241d1262508da78ff9aef%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637955336462113271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Huls%2BXn5Zu7AbZVCeSwlOupeRlrt5orN2m%2BSAcvUkdI%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKBQHJ3W6AGJNVWFRTE767DVYCL4VANCNFSM553ZGUDA&data=05%7C01%7C%7C685eb45b207241d1262508da78ff9aef%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637955336462113271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=n5HmhGur9taTBu2yX6VoJo1lm9wYnvxOdgN0TcJY%2FWI%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>
do you run playbook with elevated privileges? It requires them.
Yes, tried with and without. current playbook status:
- name: ensure jenkins container is running
hosts: localhost
connection: local
become: yes
The error still reads:
TASK [ikke_t.podman_container_systemd : create systemd service file for container: jenkins] *****************************
fatal: [localhost]: FAILED! => {"changed": false, "checksum": "630539e436b8ae828bcba4e209bcb97e0879d356", "gid": 1000, "group": "bblasco", "mode": "0644", "msg": "chown failed: [Errno 1] Operation not permitted: b'/home/bblasco/.config/systemd/user/jenkins-container-pod-bblasco.service'", "owner": "bblasco", "path": "/home/bblasco/.config/systemd/user/jenkins-container-pod-bblasco.service", "secontext": "unconfined_u:object_r:systemd_unit_file_t:s0", "size": 826, "state": "file", "uid": 1000}
The unit file actually does get created and placed correctly, but I think the module still tries to force the ownership and permissions. I have been scratching my head at this one.
what does the directory look permission wise? ls -laZ?
mine looks like this:
ikke@fediot ~]$ sudo ls -laZ ../grafana/.config/systemd/user
total 24
drwxr-xr-x. 5 grafana grafana unconfined_u:object_r:config_home_t:s0 4096 Jul 18 08:51 .
drwxr-xr-x. 3 grafana grafana unconfined_u:object_r:config_home_t:s0 4096 Dec 29 2020 ..
drwxr-xr-x. 2 grafana grafana unconfined_u:object_r:systemd_unit_file_t:s0 4096 Jan 24 2021 default.target.wants
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 910 Jul 6 22:23 grafana-container-pod-grafana.service
drwxr-xr-x. 2 grafana grafana unconfined_u:object_r:systemd_unit_file_t:s0 4096 Jan 24 2021 multi-user.target.wants
drwxr-xr-x. 2 grafana grafana unconfined_u:object_r:systemd_unit_file_t:s0 4096 Apr 24 2021 timers.target.wants
Hi, sorry for the slow reply! Looks like the SELinux contexts and directory perms are all the same.
[bblasco@micro ansible-podman-examples]$ ls -laZ /home/bblasco/.config/systemd/user/
total 4
drwxr-xr-x. 2 bblasco bblasco unconfined_u:object_r:config_home_t:s0 51 Aug 8 14:12 .
drwxr-xr-x. 3 bblasco bblasco unconfined_u:object_r:config_home_t:s0 18 Aug 8 08:52 ..
-rw-r--r--. 1 bblasco bblasco unconfined_u:object_r:systemd_unit_file_t:s0 826 Aug 8 14:12 jenkins-container-pod-bblasco.service
[bblasco@micro ansible-podman-examples]$