Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2018-12-06 at 17:49 +0100, Lennart Poettering wrote:
> On Do, 06.12.18 11:25, Simo Sorce (simo@xxxxxxxxxx) wrote:
> 
> > > > Summary: I'd make things simple, and enable all four unconditionally
> > > > and by default without any dynamic infrastructure, without postinst
> > > > scripts or anything. If that's not acceptable, then at least two of the
> > > > four should be unconditionally enabled.
> > > 
> > > I also think we should "enable" them unconditionally, in the sense that
> > > they should be configured in the default /etc/nsswitch.conf configurations.
> > > As Lennart wrote, if the module is not installed in the filesystem, that
> > > configuration has no effect. And if it is installed, but talks to an
> > > inactive service, it has almost no effect too (apart from the linkage
> > > and small runtime overhead). "Enabling" them in one consistent way in
> > > the normal distro configuration seems much better to me then patching
> > > it in, in a slightly different way on each installation.
> > > 
> > > In QA the subject of reducing the test matrix often comes up. This is
> > > a nice opportunity: let's avoid having a nsswitch line that depends on
> > > the installation order.
> > > 
> > > --
> > > 
> > > Also, we are not talking about whether those modules are active or not.
> > > They *already* *are*, on any Fedora system where the configuration was
> > > not overridden and the right packages are installed. The question is
> > > *how* they should be enabled: either through the installed file or through
> > > rpm scriptlets. Without those modules, too much stuff breaks, so disabling
> > > them is not a realistic option.
> > 
> > I wonder if we should think of a tighter system integration and subsume
> > the tasks of nss_machines into SSSD.
> > It would allow for detection and logging of UID conflicts should they
> > happen in a live system with the ability, for the admin to better
> > choose which of the pools should have priority in case of conflict ...
> 
> No disrespect, but think this would mean the layering is the wrong way
> round: sssd is an add-on currently, a layer above systemd. systemd as
> the lower layer really shouldn't call into higher layer stuff for
> registering UIDs/GIDs. I mean, conceptually, higher level stuff should
> call into lower level stuff but not the other way round. (And there's
> also the problem that sssd is hardly universally accepted. systemd
> probably runs on more systems not using sssd than on those using
> sssd.)

Which layer is above or below and handles this is not set in stone
either way. And we have many systems that call "above" (like kernel
calling to user-space), so I do not see this as a problem.

Acceptance is also not a problem, the point is integrating when and
where it makes sense on Fedora.

> Currently Linux has no nice protocol for registering UIDs or UID
> ranges. In systemd we tried to make the best from what we got, and
> what the layers underneath permit us (i.e. glibc NSS):
> 
> 1. we always register the IDs we take possession of in NSS, to make
>    sure that it can be used as a comprehensive database of UID
>    registrations. (That's what the nss modules mentioned in my earlier
>    mail are about after all).

This is fine.

> 2. When picking a UID we check with NSS first if the UID is already
>    taken.

This is where we may want to integrate. The problem is that systems
like AD and FreeIPA are represented in Linux (via SSSD or Windbind) by
allocating a range where new users will be mapped, however those UIDs
cannot be represented in NSS as they do not exist yet in the central
system. So having a place where you can ask "is this range free?/this
range is taken" sounds like is needed.

> 3. When picking a UID we also check if any IPC object is already owned
>    by the UID.

This is fine for cases where all users can be taken at once, but see
above.

> 4. When checking whether UID is used we take the lckpwdf() lock first
>    (if we can, since its in /etc, i.e. potentially read-only), in
>    order to serialize registration. This sucks a bit admittedly, since
>    strictly speaking that lock is just about the file-based database
>    (i.e. /etc/passwd and friends). But it's the best there is, and it
>    is official glibc API.

It does fall short, most enterprise installations use LDAP or other
external databases, and that lock does nothing. And in general won't be
able to do anything because the single system has no authority to grab
ranges. However the daemons that provide users to NSS have a little bit
of knowledge of what are the ranges that will be likely/certainly used
by those external services, and should be consulted when there is a
need to allocate a range, because in general the external system is the
authoritative one.
In case of conflict, it doesn't matter how painful on a single system,
it's the single system that has to change as the external system is
shared among many and is generally always considered authoritative.

> We also documented in a lot of detail the UID/GID range assumptions we
> make:
> 
> https://systemd.io/UIDS-GIDS
> 
> I think it would be great if we could come to a better protocol for
> taking possession of UID ranges in the long run.

+1

>  But I still think the
> best database for such allocation should be NSS itself, right
> now.

Except NSS can't do reservations, and those are critical.

>  What would be great if we'd at least agree on a better lock file
> though, maybe in /run.

What's the point of a lockfile ?
What we really need is a way to reserve a range, then you can do what
you need within that range in your nss module, without any lock needed
(as long as other modules respect the range assignments).

>  And maybe some rules that when you allocate
> long UID ranges at once (like container managers do), that you only
> have to NSS check key UIDs from it.

I am not sure I grok this last sentence, but yeah, the whole point is
about allocating ranges, we should come up with a way to do that
system-wide where all providers can participate.
We also need to figure out how to handle potential conflicts after
administrative changes are pushed around from either a dynamic central
system (AD/FreeIPA/LDAP) or a config managment system that only has a
view on centrally managed resources.
It doesn't have to be anything magic, but it needs to be something the
admin can act on reasonably.

Simo.

> Lennart
> 
> --
> Lennart Poettering, Red Hat
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux