podman-container-systemd icon indicating copy to clipboard operation
podman-container-systemd copied to clipboard

Rootless container deployment fails when placing systemd unit file

Open benblasco opened this issue 2 years ago • 7 comments

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

benblasco avatar Aug 08 '22 05:08 benblasco

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.

ikke-t avatar Aug 08 '22 05:08 ikke-t

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: @.***>

benblasco avatar Aug 08 '22 07:08 benblasco

do you run playbook with elevated privileges? It requires them.

ikke-t avatar Aug 08 '22 11:08 ikke-t

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.

benblasco avatar Aug 08 '22 11:08 benblasco

what does the directory look permission wise? ls -laZ?

ikke-t avatar Aug 10 '22 11:08 ikke-t

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

ikke-t avatar Aug 10 '22 11:08 ikke-t

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]$ 

benblasco avatar Aug 12 '22 04:08 benblasco