On Wed, 2017-03-08 at 11:39 +0100, Jakub Hrozek wrote:
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.
Inefficiency is secondary, the problem is that you would very quickly
get requests to have different filters for posix users and non-posix
users, and you end up adding a ton of options for the two distinct
cases. It is better if the users (and groups) for an application have
the filters required for that application and exactly only those
filters, or you'll pretty quickly have to add filtering both in the
backend and in the NSS frontend and the code becomes super-complicated
== tons of bugs and regressions.
If applications want their own view they get their special domain and
then everything can be tweaked as wanted w/o impacting the underlying
system users and their domain settings.
Simo.