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
Hi Sam,
Can you provide me a complete set of logs from both machines? The one where
pam_sss_gss.so is working fine and the problematic one?
I will take a look at them and will try to figure out what the issue is.
You can send it to me directly at ppola...@redhat.com.
Best regards,
Pawel
On
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
Whoops, I forgot to include the sudo output!
pam_sss_gss: Initializing GSSAPI authentication with SSSD
pam_sss_gss: Switching euid from 0 to 123456789
pam_sss_gss: Trying to establish security context
pam_sss_gss: SSSD User name: sam.mor...@example.net
pam_sss_gss: User domain: example.net
I have two Debian systems, and using pam_sss_gss.so for sudo works fine on one
of them, but not the other.
Both have SSSD 2.4.1 installed and are joined to FreeIPA domains.On the system
where it works, the user is defined in the FreeIPA domain.
On the system where it doesn't work, my user is
thanks Alexey! i ddint realize it coudl be configured in the config file
thought it was just a build option.
I'll give it a try and post back.
KRB5CCNAME doesnt seem to be configured anyway so i'll assume it'll default
to /tmp/krb5cc_UID
On Wed, 31 Mar 2021 at 10:06, Alexey Tikhonov wrote:
>
