-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rootless container deployment fails when placing systemd unit file #58
Comments
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 Android<https://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 GitHub<https://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 unsubscribe<https://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:
The error still reads:
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:
|
Hi, sorry for the slow reply! Looks like the SELinux contexts and directory perms are all the same.
|
I am trying to deploy a rootless container and have encountered the following issue during the deployment:
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.ymlI 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
The text was updated successfully, but these errors were encountered: