Re: [SSSD] [PATCHES] Support the 'services' NSS map in SSSD
by Jakub Hrozek
Resending after a list outage.
On Fri, Jan 27, 2012 at 11:25:26AM +0100, Jakub Hrozek wrote:
> On Thu, Jan 26, 2012 at 08:18:06PM -0500, Stephen Gallagher wrote:
> > On Fri, 2012-01-27 at 01:12 +0100, Jakub Hrozek wrote:
> > ...
> > > > #0008:
> > > > line 228: Just a nitpick I guess, but storing \0 instead of NULL to char *
> > > > field seems confusing
> > > > - in relation to sysdb_store_service(): what is the purpose of supporting
> > > > multiple protocols when only is always given to it? Is there some plan for the
> > > > future?
> > > > - I would like to point out the goto construct in the enum_services function.
> > > > If anyone else wants to ack that, feel free, but I'm not going to.
> > > >
> > > > The last thing is just a question: if you call getservbyname_r(), your
> > > > variable 'result' is filled with some values. Are all of these values part of
> > > > the buffer you are giving to that function? My concern is if the s_aliases
> > > > array is freed somewhere (for example with the buffer being freed).
> > > >
> > >
> > > Seeing the BUFLEN being set to 1024 made me wonder if the maximum
> > > service name and/or the maximum number of aliases is defined somewhere?
> > >
> >
> >
> > No, it's not specified anywhere that we can rely on, unfortunately. 1024
> > is as reasonable a guess as any other.
> >
> > ..
> >
> > > > #0012:
> > > > jhrozek is doing the review
> > >
> > > There's one thing I don't understand -- why does setservent_send() go
> > > directly to DP without ever checking the cache? I know there's the in
> > > memory getent_ctx cache but going to sysdb would persist across sssd
> > > restarts.
> > >
> > > This is different from how setpwent works, for example.
> > >
> > > The rest of the patch is looking good.
> > >
> >
> > Actually, I modeled this off of setpwent. I agree it might be better to
> > check if the enum timeout has expired (and I'm not exactly sure why we
> > haven't been doing so). If you look at nss_cmd_setgrent_step(), we
> > always set NEED_CHECK_PROVIDER and go to the DP before we call
> > sysdb_enumpwent(). We're not checking it for expiration at all.
> >
> > That said, the benefit would only really be there for the proxy
> > provider, since the LDAP provider just always returns DP_ERR_OK
> > immediately on set*ent (because it maintains its own timed update policy
> > instead of request-driven). So In the end, the most we'd gain is
> > swapping one LDB search for a trip over the socket.
> >
>
> ..actually I completely forgot about this.
>
> > In essence, I think it's probably okay to not survive a reboot on
> > enumeration here. (We can open a ticket to change this behaviour to be
> > "more correct" later).
> >
>
> Nah, not worth it.
>
> > > >
> > > > #0013:
> > > > jhrozek is doing the review
> > > >
> > > >
> > >
> > > I realize we're doing it in proxy_id.c for example, but I really don't
> > > like using goto to jump backwards. We don't need to fix it now, but I
> > > think using a loop would be so much nicer.
> > >
> >
> > I agree. As I said in my other reply to Jan, I just copy-pasted from
> > proxy_id.c to save time. We should absolutely open a ticket to fix this
> > globally.
> >
>
> https://fedorahosted.org/sssd/ticket/1156
>
> > > My only other complaint is that the sysdb_transaction_cancel() call
> > > should at least print a DEBUG() message on failure.
> > >
> >
> > Fixed. I also noticed and fixed a bug with the in_transaction logic
> > where I was setting it to false regardless of the return value from the
> > sysdb_transaction_commit().
> >
>
> May a suggest a wrapper macro? :-)
>
> > > I had already reviewed the rest of the patches I haven't covered in this
> > > review.
> >
> >
> > Patches re-attached. To eliminate confusion, these contain the changes
> > from Jan's review as well.
> >
> >
>
> I'm fine with the patches now. Ack from me.
12 years, 2 months
[PATCH] DP: Refactor responder_dp_req so it's reusable by other responders
by Jakub Hrozek
A number of new responders is currently being developed in addition to
the existing NSS and PAM responders that only deal with accounts. The
new responders often deal with different data such as automounter maps
or sudoer rules. It is prudent to let these responders communicate with
back ends using their own protocol.
Attached is a patch that refactors the requests in Data Provider so that
they are more generic. The commits message is slightly more verbose than
usual this time to explain all the changes.
I'm going to include a sudo request shortly as an example of a new
non-account request.
[PATCH] DP: Refactor responder_dp_req so it's reusable by other responders:
* the internal requst is now more generic and is decoupled from
account-specific data. There is a new sss_dp_issue_request() wrapper
that issues a BE request or registers a callback
* the public requests all use struct sss_dp_req_state as the tevent_req
state data. This allows to report back data from the internal request
even if the caller is just a callback notifier
* each specific request now uses an _info structure that contains all
the data necessary to construct a DBusMessage passed to provider
* each specific request now defines a sss_dp_get_$data_msg callback that
is called from the sss_dp_issue_request() common wraper. The purpose
of the wrapper is to construct a DBusMessage and bind it to a DBus
method so the message can be just sent over to back end
The miscellanous changes include:
* change SSS_DP_ constants to an enum. This way, a switch() would error
if a value is not handled.
* rename sss_dp_get_account_int_send() to sss_dp_internal_get_send()
request because the internal request is going to handle more than just
account data
The patch must be applied on top of all Stephen's patches that are
currently on the list, including the services support.
12 years, 2 months
Mailing List Outage
by Stephen Gallagher
There was an unplanned outage in the Fedora Infrastructure mailing lists
last night. Any messages sent to this list (and many others) were being
denied with a "no such list" error.
If you received such a message, please resubmit your emails. The list is
back up and running.
12 years, 2 months
PAM: Do not overwrite ret
by Jakub Hrozek
If pam_check_user_search returned ENOENT, we would rewrite the ENOENT
value stored in "ret" witch EOK returned from pam_initgr_cache_set().
"ret" is then used to decide whether to call pam_dp_forwarder or not.
I think we shouldn't add user to cache on ENOENT, we are not
implementing negative cache in the PAM responder.
12 years, 2 months
[PATCHES][PRELIMINARY] Support the 'services' NSS map in SSSD
by Stephen Gallagher
These patches add support for getservbyname() and getservbyport() to
the NSS responder. They do not yet support enumeration of services
through setservent(), getservent() and endservent(). These patches also
include a reference implementation using the proxy ID provider (which I
used to test and validate the functionality).
Work still to come: enumeration support and LDAP provider
implementation.
Patch 0001: Make the sized_string structure available elsewhere in the
source.
Patch 0002: Add support for strtouint16 (needed for managing the port
number)
Patch 0003: Make add_string() and add_ulong() available to all sysdb
files.
Patch 0004: Add routines to save, delete and modify service entries in
the sysdb. (Also includes some very rudimentary unit tests)
Patch 0005: Add LDB indexes for the port and protocol arguments, since
we'll be searching on them.
Patch 0006: Add support to the NSS sss_client to look up getservbyname()
and getservbyport().
Patch 0007: Add support for services in dp requests
Patch 0008: Add routines to the negative cache to handle services
Patch 0009: The big one. This patch adds a new feature to the NSS
responder to handle looking up services by name and by port (optionally
filtering by protocol).
Important note: I did not use the existing check_cache() functionality
here. I changed the cache check and lookup logic to match that which was
proposed in https://fedorahosted.org/sssd/ticket/1126 (to deal with
multiple domains more efficiently). I would like this very carefully
reviewed (by two engineers) because I think our long-term plan is going
to be to migrate the existing NSS responders over to this style.
/* Provider Lookup Logic:
* Iterate through the available caches. If the cached entry is
* present and not expired, return it immediately(*). If it is
* present and expired, add it to a list of domains eligible to
* be checked. If it is in the negative cache, skip over it and
* do not add it to the eligible domain list.
*
* Once we have searched all of the caches, if the entry has not
* been determined to be available, search all domains in order
* to see if any of them contain the requested entry.
*
* (*) Optionally perform a midpoint cache refresh if appropriate.
*/
See the functions getserv_send() and lookup_service_*() for more
details.
Patch 0010: This is the reference implementation I used for testing
purposes. I tested against proxy_lib_name = files (and changed the
'services' line in my /etc/nsswitch.conf to contain only 'sss')
12 years, 2 months
sssd on RHEL5 w/ OpenLDAP backend issues
by Eric
Hello,
I have searched for an appropriate list to post this question and figured this was the best I could find and apologize in advance
for the wasted bandwidth and chatter. Just point me to the right direction.
I am trying to implement a password policy (i.e. password expiration (max age), password history, etc) on RHEL 5.
I am kind of at a loss. Is there any plans to add functionality into sssd for RHEL5 that will give this type of functionality?
See below for details on what I have tried.
I was hoping to use sssd with the backend of OpenLDAP 2.4.26 since this is used extensively at my organization already.
I tried using the ppolicy overlay from OpenLDAP, but that does not provide any feedback to the user about pending password
expiration via sssd.
So at the time and date of expiration, the user is unable to login without any prior warning and is unable to login.
Instead I see the following in /var/log/sssd/sssd_LDAP.log
[sssd[be[LDAP]]] [sdap_control_create] (3): Server does not support the requested control [1.3.6.1.4.1.42.2.27.8.5.1].
The above apparently is the ldap contral which gives the warning about password expiration which sssd does not see.
I then attempted to turn on "ldap_pwd_policy = shadow" in /etc/sssd/sssd.conf I was then unable to change the password
via passwd(1) command.
I see the following:
[testuser@rhel5server ~]$ passwd
Changing password for user testuser.
Current Password:
New UNIX password:
Retype new UNIX password:
passwd: Module is unknown
--------------------------------------
I do not see any warnings or message upon login if testuser account is about to expire.
If I bind as testuser with ppolicy active I get the following (sanitized):
ldapsearch -x -D uid=testuser,ou=People,o=myorg -W -H ldaps://ldaptest.domain.myorg -b uid=testuser,ou=People,o=myorg -e ppolicy
ldap_bind: Success (0) (Password expired, 2 grace logins remain)
# extended LDIF
#
# LDAPv3
# base <uid=testuser,ou=People,o=myorg> with scope subtree
# filter: (objectclass=*)
# requesting: *
#
# testuser, People, myorg
dn: uid=testuser,ou=People,o=myorg
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: testuser
sn: testuser
cn: testUser
gecos: Test User
uidNumber: 5555
gidNumber: 5555
homeDirectory: /home/testuser
loginShell: /bin/bash
shadowLastChange: 14998
shadowExpire: 21917
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 370
shadowInactive: 180
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
--------------------------------------
With ldap_pwd_policy = shadow:
In /var/log/sssd/pam_LDAP.log (sanitized)
[sssd[be[LDAP]]] [check_pwexpire_shadow] (4): Password expired.
[sssd[be[LDAP]]] [sdap_auth4chpass_done] (7): user [uid=testuser,ou=People,o=myorg] successfully authenticated.
[sssd[be[LDAP]]] [sdap_auth4chpass_done] (1): Changing shadow password attributes not implemented.
[sssd[be[LDAP]]] [be_pam_handler_callback] (4): Backend returned: (3, 28, <NULL>) [Internal Error (Module is unknown)]
[sssd[be[LDAP]]] [be_pam_handler_callback] (4): Sending result [28][LDAP]
----------------------------------------
I am running rhel5:
rpm -qa sssd\*
sssd-1.5.1-37.el5
sssd-client-1.5.1-37.el5
--------------------------------------
My /etc/sssd/sssd.conf (sanitized):
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = LOCAL,LDAP
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 600
[pam]
reconnection_retries = 3
[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
access_provider = permit
ldap_schema = rfc2307
ldap_uri = ldaps://ldaptest.domain.myorg
ldap_search_base = o=myorg
ldap_tls_reqcert = demand
ldap_tls_cacertdir = /etc/openldap/cacerts
cache_credentials = true
enumerate = true
ldap_default_bind_dn = cn=testsa,ou=Manager,o=myorg
ldap_default_authtok_type = password
ldap_default_authtok = <secret>
ldap_user_search_base = ou=People,o=myorg
ldap_user_object_class = posixAccount
ldap_user_uuid = entryUUID
ldap_group_search_base = ou=Group,o=myorg
ldap_netgroup_search_base = ou=Netgroup,o=myorg
entry_cache_timeout = 60
ldap_pwd_policy = shadow
---------
/etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
account required pam_access.so accessfile=/etc/security/access-sssd.conf
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session required pam_mkhomedir.so umask=0077 skel=/etc/skel/
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
---------
Any plans to update sssd to either support shadow attribute updates?
I read in the sssd-ldap man
"shadow - Use shadow(5) style attributes to evaluate if the password has expired. Note that the current version of
sssd cannot update this attribute during a password change."
Any plans to update sssd for RHEL5 to support "Controls used for Password Policy" found in
http://tools.ietf.org/html/draft-behera-ldap-password-policy-07.
I can provide more information upon request.
Any help with this would be greatly appreciated.
Thanks in advance,
-Eric
12 years, 2 months