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.
It is really much safer to set a separate domain for the POSIX and
non-POSIX world.
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
