[PATCH] Move ccache operations to krb5_child, allow the krb5_auth code to run unprivileged
by Jakub Hrozek
Hi,
attached are patches that apply on top of my previous ldap_child and
selinux_child patches. The complete branch (including tests I'm still
working on) can be inspected here:
https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/log/?h=nonroot
Simo, Sumit, I added you to CC directly, b/c I suspected you wanted to be
included in larger krb5_child changes..
Below are patch descriptinons of the individual changes.
[PATCH 1/6] BUILD: Install krb5_child as suid if running under non-privileged user
If sssd_be is running unprivileged, then krb5_child must be setuid to be
able to access the keytab and become arbitrary user.
[PATCH 2/6] KRB5: Drop privileges in the child, not the back end
In future patches, sssd_be will be running as a non-privileged user, who
will execute the setuid krb5_child. In this case, the child will start
as root and drop the privileges as soon as possible.
[PATCH 3/6] KRB5: Move ccache-related functions to krb5_ccache.c
Add a new module krb5_ccache.c that contains all ccache-related
operations. The only user of this module shall be krb5_child.c as the
other modules will run unprivileged and accessing the keytab requires
either privileges of root or the ccache owner.
This patch only /moves/ code, the changes will come in later patches.
[PATCH 4/6] KRB5: Move checking for illegal RE to krb5_utils.c
Otherwise we would have to link krb5_child with pcre and transfer the
regex, which wold be cumbersome. Check for illegal patterns when
expanding the template instead.
[PATCH 5/6] KRB5: Move all ccache operations to krb5_child.c
The credential cache operations must be now performed by the krb5_child
completely, because the sssd_be process might be running as the sssd
user who doesn't have access to the ccaches.
src/providers/krb5/krb5_ccache.c is still linked against libsss_krb5
until we fix Kerberos ticket renewal as non-root.
Also includes a new error code that indicates that the back end should
remove the old ccache attribute -- the child can't do that if it's
running as the user.
[PATCH 6/6] KRB5: Do not switch_creds() if already the specified user
The code didn't have to handle this case previously as sssd_be was always
running as root and switching to the ccache as the user logging in.
Also handle NULL creds on restore_creds() in case there was no switch.
One less if-condition and fewer indentation levels.
Thank you for the review.
9 years, 4 months
Removing uidNumberfrom SSSD Search Filter
by Nathan Robbins
I am running into an interesting problem with our LDAP server. It’s an old system that has been in place for a long time we cannot change the schema. Basically I can’t change the LDAP server configuration.
We do no make use of the uidNumber and gidNumber fields in our configuration.
I am trying to set up a box for authentication only to the LDAP server.
I have set up and configured SSSD and it can talk to the LDAP server.
The problem is: (&(uidNumber=*)(!(uidNumber=0)) is included in my search filter (based on the LDAP server logs) and since that attribute is not used in our system, it causes SSSD to not return any entries.
This is the log returned from the LDAP server:
Nov 11 16:12:00 13.x.x.x dsprd70-acc: [11/Nov/2014:16:11:16 -0600] conn=413208 op=4 msgId=5 - RESULT err=0 tag=101 nentries=0 etime=0 notes=U
Nov 11 16:12:00 13.x.x.x dsprd70-acc: [11/Nov/2014:16:11:16 -0600] conn=413208 op=4 msgId=5 - SRCH base="ou=people,dc=xxxx,dc=xxx,c=us" scope=2 filter="(&(uid=theuserid)(objectClass=inetOrgPerson)(&(uidNumber=*)(!(uidNumber=0))))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute authorizedservice accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap"
As you can see, it appends the (&(uidNumber=*)(!(uidNumber=0)) to the search filter and it seems to do this no matter what I do. I can use ldapsearch and remove only that part of the filter and i get results.
I need a way to tell SSSD to not try and filter the uidNumber attribute for me. Basically I need that to not be in the filter sent to my ldap server. Ideas
sssd.conf :
[domain/LDAP]
enumerate = False
cache_credentials = False
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://lldapserver:port
ldap_id_use_start_tls = True
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_search_base = ou=People,dc=xxxxx,dc=xxxx,c=us
ldap_default_bind_dn = uid=xxxxx,ou=xxxx,dc=xxxxx,dc=xxxx,c=us
ldap_schema = rfc2307
ldap_default_authtok_type = password
ldap_default_authtok = xxxxxxxx
ldap_user_object_class = inetOrgPerson
ldap_search_timeout = 60
ldap_network_timeout = 60
debug_level = 4
min_id = 0
[sssd]
services = nss, pam
config_file_version = 2
domains = LDAP
[nss]
homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
9 years, 4 months
Problems with SSSD RPM subpackage ordering
by Jakub Hrozek
Hi,
a downstream installation test was failing with our recent packaging
changes that involve creatig the sssd user. It turns out that
sssd-krb5-common (which contains krb5_child, owned by the sssd user) got
installed by yum before sssd-common, which creates the sssd user during
the %pre scriptlet.
I spent some time talking to the RPM developers on IRC and the result
was this RPM bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1163086
The RPM developers suggest that the bug might still be in SSSD, but we
couldn't figure out anything that would cause sssd-krb5-common to be
installed before sssd-common, as the sssd-krb5-common subpackage
Requires sssd-common.
In downstream, I worked around the issue by creating the sssd user
(unless it exists already) in each subpackage that owns files as the
sssd user. I know it's a hack, but it was the only way we could unblock
the downstream soon.
Now my question is whether to also include the same change in downstream
spec as well? It's clearly a workaround, but at the same time, it might
hit users of our downstream spec, so I say we should include the same
change as well.
Also, does anyone spot an issue with our Requires? I couldn't see any,
but maybe I just overlooked it..
Finally, I'm not sure if using %pretrans is an option, since the scriptlet
would run before /any/ packages are installed, including shadow-utils.
9 years, 4 months
[PATCH] AD: Change level of debug message
by Lukas Slebodnik
ehlo,
I was analysing some log files and I found that message "DNS update finished"
is too verbose. (at least if we want enable levels 0-2 be default in journald)
Simple patch is attched.
LS
9 years, 4 months
memory cache for initgroups
by Jakub Hrozek
Hi,
we had short discussion on $SUBJECT with Simo on IRC already, but there
are multiple people involved from multiple timezones, so I think a mailing
list thread would be better trackable.
Can we add another memory cache file to SSSD, that would track
initgroups/getgrouplist results for the NSS responder? I realize initgroups
is a bit different operation than getpw{uid,nam} and getgr{gid,nam} but
what if the new memcache was only used by the NSS responder and at the
same time invalidated when initgroups is initiated by the PAM responder
to ensure the memcache is up-to-date?
I already know about two projects that would benefit from faster initgroups
operation - GlusterFS uses getgrouplist() quite a lot with some setups
and also in the IPA server mode, the SSSD running on the server becomes
a bit of a bottlenec for some operations.
Are there any technical reasons against a new memcache file that would
cache initgroups?
9 years, 4 months