On Wed, Mar 08, 2017 at 10:45:32AM +0100, Pavel Březina wrote: > On 03/07/2017 03:11 PM, Jakub Hrozek wrote: > > On Tue, Mar 07, 2017 at 02:31:27PM +0100, Pavel Březina wrote: > > > On 03/07/2017 01:33 PM, Jakub Hrozek wrote: > > > > On Tue, Mar 07, 2017 at 01:18:36PM +0100, Pavel Březina wrote: > > > > > On 03/07/2017 01:16 PM, Pavel Březina wrote: > > > > > > On 03/06/2017 02:49 PM, Jakub Hrozek wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I prepared a design page for a new feature about fetching and > > > > > > > authenticating non-POSIX users: > > > > > > > > > > > > > > https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html > > > > > > > > > > > > > > For your convenience, I'm also copying the .rst text below: > > > > > > > > > > > > > > Support for non-POSIX users and groups > > > > > > > ====================================== > > > > > > > > > > > > > > Related ticket(s): > > > > > > > ------------------ > > > > > > > https://pagure.io/SSSD/sssd/issue/3310 > > > > > > > > > > > > I find this document quite hard to understand, so I want to ensure > > > > > > I get > > > > > > it right: > > > > > > > > > > > > 1) You can't have one domain that return both posix and non-posix > > > > > > users. > > > > > > 2) PAM is allowed to login a non-posix users for given services. > > > > > > 3) If CACHE_REQ_APP is used, non-posix domains are searched first > > > > > > then > > > > > > posix domains. > > > > > > 4) If CACHE_REQ_POSIX is used, non-posix domains are skipped. > > > > > > 5) Non-posix domains require fully qualified name. > > > > > > 6) Posix users return only posix groups membership. > > > > > > 7) Non-posix users return both posix and non-posix membership. > > > > > > > > > > And > > > > > 8) You can have two users, one posix, one non-posix with the same > > > > > name. > > > > > > > > In theory yes, but I don't think this would be too common. In general > > > > you could have two entries, one with objectclass user, the other with > > > > objectclass posixUser where each domain would use a different attribute > > > > for the username. But even so, I think the current scheme would protect > > > > us against these strange setups. > > > > > > If find this rather complicated at least from what we talked about on irc. > > > If I recall correctly, we leaned in a way that we always download the user > > > whether it is posix or not and then let the caller decide if it should be > > > returned by sssd. I.e. > > > > > > if !non_posix_users_enabled(domain) then > > > download only posix users > > > else > > > download user even if it is non posix > > > > > > In NSS (and other posix responders) we would return ENOENT for non-posix > > > users. In IFP we would not care (or care if we change API to select). > > > > > > This wouldn't require the domain separation. What were the reasons to not > > > use this approach? > > > > The conflicts between different 'views'. Consider the case where an IFP > > user would request the groups of a user who is a member of both POSIX and > > non-POSIX groups. Then, a second later, the NSS responder calls > > initgroups. > > > > What does the initgroups POSIX call on the back end level do with the > > non-POSIX groups, especially the leaf ones? Does it remove them? Do we > > add logic to ignore the non-POSIX groups? How do we tell if the groups > > were removed from the server if the searches match only the POSIX data > > in the second request? > > In this approach, backend is supposed to always download both posix and > non-posix users. Backend should not be aware about posix attributes at all. > Responder should decide whether non-posix users should be removed from the > result (not from the cache) or not.
This would be hugely inefficient and e.g. logins would take forever. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
