10:21 a.m.
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.
--
Tero
10:35 a.m.
Hi,
On Thu, Nov 26, 2020 at 5:24 PM Tero Saarni <tero.saarni(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
10:50 a.m.
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.
--
Tero
11:21 a.m.
On Thu, Nov 26, 2020 at 5:52 PM Tero Saarni <tero.saarni(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
12:10 p.m.
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.
--
Tero
4:47 a.m.
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
2:59 a.m.
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
9:14 a.m.
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
11:02 a.m.
We are also trying to run as a non-root user with minimal capabilities in production. Has
anymore work been done on this since?
5:28 p.m.
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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Paweł Poławski
Senior Software Engineer
Red Hat <https://www.redhat.com/>
ppolawsk(a)redhat.com
@RedHat <https://twitter.com/redhat> Red Hat
<https://www.linkedin.com/company/red-hat> Red Hat
<https://www.facebook.com/RedHatInc>
<https://red.ht/sig>
3:20 p.m.
On Thu, Apr 1, 2021 at 6:06 PM David Mather <davidmather(a)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.
4:03 p.m.
On Thu, Mar 21, 2024 at 10:21 PM Alexey Tikhonov <atikhono(a)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.
--
Tero
8:46 a.m.
On Thu, Mar 21, 2024 at 10:04 PM Tero Saarni <tero.saarni(a)gmail.com> wrote:
On Thu, Mar 21, 2024 at 10:21 PM Alexey Tikhonov
<atikhono(a)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
11:03 a.m.
On Fri, Mar 22, 2024 at 3:46 PM Alexey Tikhonov <atikhono(a)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
12:04 p.m.
On Fri, Mar 22, 2024 at 5:03 PM Tero Saarni <tero.saarni(a)gmail.com> wrote:
On Fri, Mar 22, 2024 at 3:46 PM Alexey Tikhonov
<atikhono(a)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-...
(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.
1:13 p.m.
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-...
(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.
--
Tero
2:10 p.m.
Hi Tero,
On Mon, Apr 8, 2024 at 8:13 PM Tero Saarni <tero.saarni(a)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**.
2:22 p.m.
On Mon, Apr 8, 2024 at 10:10 PM Alexey Tikhonov <atikhono(a)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
5:33 a.m.
On Mon, Apr 8, 2024 at 9:22 PM Tero Saarni <tero.saarni(a)gmail.com> wrote:
On Mon, Apr 8, 2024 at 10:10 PM Alexey Tikhonov
<atikhono(a)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?
7:31 a.m.
On Tue, Apr 9, 2024 at 1:34 PM Alexey Tikhonov <atikhono(a)redhat.com> wrote:
On Mon, Apr 8, 2024 at 9:22 PM Tero Saarni
<tero.saarni(a)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
15
days inactive
1245
days old
sssd-users@lists.fedorahosted.org
20 comments
5 participants
participants (5)
-
Alexey Tikhonov -
David Mather -
Lukas Slebodnik -
Pawel Polawski -
Tero Saarni