Hi,
I'm trying to run SSSD inside docker container without root user. The container is executed in OpenShift cluster which does not allow running as root inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment.
Hi,
On Thu, Nov 26, 2020 at 5:24 PM Tero Saarni tero.saarni@gmail.com wrote:
Hi,
I'm trying to run SSSD inside docker container
Could you please describe your use case in greater details?
Who is the consumer of services provided by sssd? What backends (data sources) do you plan to use?
without root user. The container is executed in OpenShift cluster which does not allow running as root inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment.
-- Tero _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Could you please describe your use case in greater details?
Who is the consumer of services provided by sssd? What backends (data sources) do you plan to use?
Thank you for your response.
The consumer is a custom (existing) application that depends on PAM libraries. The data source is LDAP backend.
On Thu, Nov 26, 2020 at 5:52 PM Tero Saarni tero.saarni@gmail.com wrote:
Could you please describe your use case in greater details?
Who is the consumer of services provided by sssd? What backends (data sources) do you plan to use?
Thank you for your response.
The consumer is a custom (existing) application that depends on PAM libraries.
(sorry for probably lame question but my knowledge about containers is very limited)
Does it mean your application is run within the same container as sssd? If this is the case, this might be not the best idea, as due to caching in every instance (and other reasons) this might turn out to be a very "heavy" solution...
The data source is LDAP backend.
-- Tero _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Does it mean your application is run within the same container as sssd? If this is the case, this might be not the best idea, as due to caching in every instance (and other reasons) this might turn out to be a very "heavy" solution...
Yes the application runs in the same container as sssd, but there is no intention to run that many instances. Caching locally at each pod / container is OK, and this setup has worked for quite some time, but now the application should be ported to run on OpenShift and I bumped into the problem of SSSD not starting as non-root.
On (26/11/20 16:21), Tero Saarni wrote:
Hi,
I'm trying to run SSSD inside docker container without root user. The container is executed in OpenShift cluster which does not allow running as root inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment.
There is a way how to run sssd as non-root but /usr/sbin/sssd still require bunch of linux capabilities to achieve that.
Here is the list: audit_write chown dac_override dac_read_search fowner ipc_lock kill net_admin setgid setuid sys_admin sys_nice sys_resource
# sys_resource is optional and not needed with default configuration
And openshift unprivileged pod has jsut following capabilities chown, dac_override, fowner, fsetid, setpcap, net_bind_service, net_raw, sys_chroot, audit_write, setfcap
Folowing two are the most problematic: setgid setuid but they are removed from default set in the openshift by default.
You would need to run sssd with differet security context than restricted https://www.openshift.com/blog/introduction-to-security-contexts-and-sccs
HTH
LS
Lukas Slebodnik wrote:
There is a way how to run sssd as non-root but /usr/sbin/sssd still require bunch of linux capabilities to achieve that.
One more question, which I should have mentioned in my previous reply.
Since there are few places in the code that check explicitly for root and exit with error if getuid() != 0 for example here https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L2449. Since these checks do not seem to be optional, adding capabilities alone do not help.
How do the maintainers feel about making sssd run on OpenShift? Would this be something to pursue / possibly contribute to?
-- Tero
On (01/12/20 08:59), Tero Saarni wrote:
Lukas Slebodnik wrote:
There is a way how to run sssd as non-root but /usr/sbin/sssd still require bunch of linux capabilities to achieve that.
One more question, which I should have mentioned in my previous reply.
Since there are few places in the code that check explicitly for root and exit with error if getuid() != 0 for example here https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L2449. Since these checks do not seem to be optional, adding capabilities alone do not help.
It is not just about `if getuid() != 0` in the monitor code. there are also other places in {krb5/ldap}_child which try to escalate privileges if they run as unprivileged user and it woudl not be allwed due to missing CAP_SETGID, CAP_SETUID And bunch of other places.
How do the maintainers feel about making sssd run on OpenShift? Would this be something to pursue / possibly contribute to?
As I mentioned in previous email you can run sssd in OpenShift but not with restricted scc.
If you really want to run it in restricted scc you can use LD_PRELOAD to pretend execution as root e.g. fakeroot https://nixdoc.net/man-pages/Linux/man1/fakeroot.1.html
It is used in sssd CI for some testing but it is not meant for production. But feel free to use it if you feel brave enough :-)
LS
We are also trying to run as a non-root user with minimal capabilities in production. Has anymore work been done on this since?
Hi David,
Plan for the full support of SSSD running as a non-root user is in scope of interest of the SSSD dev team. I can't provide you a precise time frame for this but some preparation already started. This transition is not trivial as by design SSSD was alway running as a root. Keep in mind that on top of the code changes a lot of testing needs to be done to confirm that the final result will be secure and perform well.
After fast check those are some of already existing upstream issues related to SSSD running without root: https://github.com/SSSD/sssd/issues/3412 https://github.com/SSSD/sssd/issues/5508 https://github.com/SSSD/sssd/issues/5536 https://github.com/SSSD/sssd/issues/5443
Best regards, Pawel
On Thu, Apr 1, 2021 at 6:06 PM David Mather davidmather@live.ie wrote:
We are also trying to run as a non-root user with minimal capabilities in production. Has anymore work been done on this since? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Apr 1, 2021 at 6:06 PM David Mather davidmather@live.ie wrote:
We are also trying to run as a non-root user with minimal capabilities in production. Has anymore work been done on this since?
It's been awhile but... quite a lot of work has been done: see https://github.com/SSSD/sssd/issues/5443#issuecomment-2013505460 for the list and TODO list in the description of https://github.com/SSSD/sssd/pull/7193 for remaining bits.
Upcoming sssd-2.10 should be capable of running in an unprivileged container without user-ns support (i.e. still OCP, but Kubernetes already has this feature).
I could also build a general purpose SSSD container image, but I would need to understand requirements / typical use cases and see an interest / demand for this.
On Thu, Mar 21, 2024 at 10:21 PM Alexey Tikhonov atikhono@redhat.com wrote:
It's been awhile but... quite a lot of work has been done: see https://github.com/SSSD/sssd/issues/5443#issuecomment-2013505460 for the list and TODO list in the description of https://github.com/SSSD/sssd/pull/7193 for remaining bits.
Upcoming sssd-2.10 should be capable of running in an unprivileged container without user-ns support (i.e. still OCP, but Kubernetes already has this feature).
I could also build a general purpose SSSD container image, but I would need to understand requirements / typical use cases and see an interest / demand for this.
Very impressive work!
Not sure if there could be a use case for *generic* container. At least in my use case we add client applications inside the same container, which makes it non-generic. But surely it would be of great value to have an *example* on how to configure and run sssd within a non-root container for this kind of purpose.
On Thu, Mar 21, 2024 at 10:04 PM Tero Saarni tero.saarni@gmail.com wrote:
On Thu, Mar 21, 2024 at 10:21 PM Alexey Tikhonov atikhono@redhat.com wrote:
It's been awhile but... quite a lot of work has been done: see https://github.com/SSSD/sssd/issues/5443#issuecomment-2013505460 for the list and TODO list in the description of https://github.com/SSSD/sssd/pull/7193 for remaining bits.
Upcoming sssd-2.10 should be capable of running in an unprivileged container without user-ns support (i.e. still OCP, but Kubernetes already has this feature).
I could also build a general purpose SSSD container image, but I would need to understand requirements / typical use cases and see an interest / demand for this.
Very impressive work!
Not sure if there could be a use case for *generic* container. At least in my use case we add client applications inside the same container
Is this a "single UID" container (i.e. SSSD and client apps run under the same UID within container namespace)? What do you use as an entry point of the container / how do you manage (start of) multiple processes?
What authentication means do you use? If this is Kerberos, does your app use TGT acquired during authentication?
, which makes it non-generic. But surely it would be of great value to have an *example* on how to configure and run sssd within a non-root container for this kind of purpose.
-- Tero
On Fri, Mar 22, 2024 at 3:46 PM Alexey Tikhonov atikhono@redhat.com wrote:
Is this a "single UID" container (i.e. SSSD and client apps run under the same UID within container namespace)? What do you use as an entry point of the container / how do you manage (start of) multiple processes?
What authentication means do you use? If this is Kerberos, does your app use TGT acquired during authentication?
Yes single UID container with simple init (no systemd). Both SSSD and client applications run within the same container. In our use case we use only LDAP domains for now, no Kerberos.
-- Tero
On Fri, Mar 22, 2024 at 5:03 PM Tero Saarni tero.saarni@gmail.com wrote:
On Fri, Mar 22, 2024 at 3:46 PM Alexey Tikhonov atikhono@redhat.com wrote:
Is this a "single UID" container (i.e. SSSD and client apps run under the same UID within container namespace)? What do you use as an entry point of the container / how do you manage (start of) multiple processes?
What authentication means do you use? If this is Kerberos, does your app use TGT acquired during authentication?
Yes single UID container with simple init (no systemd). Both SSSD and client applications run within the same container. In our use case we use only LDAP domains for now, no Kerberos.
What platform is this? Is it still ``` The container is executed in OpenShift cluster which does not allow running as root inside container. ``` as in your original email in this thread?
JFTR: Openshift should eventually get https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-use... (i.e. 'user namespaces' support) so that pod fully restricted in the host namespace can be run fully unrestricted in the container user-ns (including running with uid=0 in container namespace while uid!=0 in host namespace).
Having said that, and taking into account 'user-ns' support isn't available yet, you might want to try builds from https://copr.fedorainfracloud.org/coprs/g/sssd/nightly/ : currently Fedora rawhide, Centos-stream 9 and Rhel 9 packages there are built '--with-sssd-user=sssd' and main SSSD process can be run directly under 'sssd' user.
Since you don't need Kerberos / handle keytabs and user TGTs, it should work out of the box.
Your feedback and observations are welcome.
What platform is this? Is it still
The container is executed in OpenShift cluster which does not allow running as root inside container.as in your original email in this thread?
JFTR: Openshift should eventually get https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-use... (i.e. 'user namespaces' support) so that pod fully restricted in the host namespace can be run fully unrestricted in the container user-ns (including running with uid=0 in container namespace while uid!=0 in host namespace).
Having said that, and taking into account 'user-ns' support isn't available yet, you might want to try builds from https://copr.fedorainfracloud.org/coprs/g/sssd/nightly/ : currently Fedora rawhide, Centos-stream 9 and Rhel 9 packages there are built '--with-sssd-user=sssd' and main SSSD process can be run directly under 'sssd' user.
Since you don't need Kerberos / handle keytabs and user TGTs, it should work out of the box.
Your feedback and observations are welcome.
Hi Alexey,
I tried and it did work. Do you have a plan for a release schedule for the feature?
Yes, it is still OpenShift. We are aware of user namespaces eventually coming too, but regardless it's cool to see non-root support in SSSD. Thank you for your work.
Hi Tero,
On Mon, Apr 8, 2024 at 8:13 PM Tero Saarni tero.saarni@gmail.com wrote:
Having said that, and taking into account 'user-ns' support isn't
available yet, you might want to try builds from https://copr.fedorainfracloud.org/coprs/g/sssd/nightly/ : currently Fedora rawhide, Centos-stream 9 and Rhel 9 packages there are built '--with-sssd-user=sssd' and main SSSD process can be run directly under 'sssd' user.
Since you don't need Kerberos / handle keytabs and user TGTs, it should work out of the box.
Your feedback and observations are welcome.
Hi Alexey,
I tried and it did work.
Out of curiosity: I realized that 'sssd/nightly' packages are built with 'systemd' support and thus 'Requires:" it. How did you work around this? I have another PR - https://github.com/SSSD/sssd/pull/7262 - that I use as a playground to build "minimal dependencies" SSSD, more suitable to run within a container (copr builds are available at https://copr.fedorainfracloud.org/coprs/g/sssd/pr7262/ ) Those builds don't require 'systemd' explicitly, but they require libdbus-1 that, unfortunately, requires libsystemd.
Do you have a plan for a release schedule for the feature?
Do you mean "improved ability to run under 'sssd' user"? There are quite a few issues that remain to be addressed. We cautiously plan to have an upstream release in time to use it in Fedora 41 and RHEL10, but **no promises**.
On Mon, Apr 8, 2024 at 10:10 PM Alexey Tikhonov atikhono@redhat.com wrote:
Out of curiosity: I realized that 'sssd/nightly' packages are built with 'systemd' support and thus 'Requires:" it. How did you work around this? I have another PR - https://github.com/SSSD/sssd/pull/7262 - that I use as a playground to build "minimal dependencies" SSSD, more suitable to run within a container (copr builds are available at https://copr.fedorainfracloud.org/coprs/g/sssd/pr7262/ ) Those builds don't require 'systemd' explicitly, but they require libdbus-1 that, unfortunately, requires libsystemd.
Actually, I did not use the packages. I compiled myself from github master.
Do you have a plan for a release schedule for the feature?
Do you mean "improved ability to run under 'sssd' user"? There are quite a few issues that remain to be addressed. We cautiously plan to have an upstream release in time to use it in Fedora 41 and RHEL10, but **no promises**.
Thanks for the info!
Yes I *think* that PR is what I mean, though I must confess I did not go through the changes listed there, to have a good understanding on what went in to enable non-root / single UID container use case.
-- Tero
On Mon, Apr 8, 2024 at 9:22 PM Tero Saarni tero.saarni@gmail.com wrote:
On Mon, Apr 8, 2024 at 10:10 PM Alexey Tikhonov atikhono@redhat.com wrote:
Out of curiosity: I realized that 'sssd/nightly' packages are built with 'systemd' support and thus 'Requires:" it. How did you work around this? I have another PR - https://github.com/SSSD/sssd/pull/7262 - that I use as a playground to build "minimal dependencies" SSSD, more suitable to run within a container (copr builds are available at https://copr.fedorainfracloud.org/coprs/g/sssd/pr7262/ ) Those builds don't require 'systemd' explicitly, but they require libdbus-1 that, unfortunately, requires libsystemd.
Actually, I did not use the packages. I compiled myself from github master.
What ./configure options do you use?
On Tue, Apr 9, 2024 at 1:34 PM Alexey Tikhonov atikhono@redhat.com wrote:
On Mon, Apr 8, 2024 at 9:22 PM Tero Saarni tero.saarni@gmail.com wrote:
Actually, I did not use the packages. I compiled myself from github master.
What ./configure options do you use?
Right, I had a dependency todards systemd regardless of compiling from source or not. I just did a quick proof-of-concept test on my own personal environment & base image, which was not based on Fedora - that was the basic reason why I used source.
Having the option for minimal dependencies surely is much better!
-- Tero
sssd-users@lists.fedorahosted.org
-
Alexey Tikhonov -
David Mather -
Lukas Slebodnik -
Pawel Polawski -
Tero Saarni