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 Mi, 12.12.18 10:10, Simo Sorce (simo@xxxxxxxxxx) wrote:

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

Well, systemd is not a Fedora-only project. It's in fact an excercise
in unification across distros, and hence interfacing with upper layer
stuff that isn't accepted standard outside of Fedora is always a
problem.

> > 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.

My recommendation would be to simply synthesize "reservation" users on
these UIDs as long as you are not assigning them to a real user, that
makes sure noone else can take them. i.e. call them "sssd-rsrvd0",
"sssd-rsrvd1", … or so, and return a synthetic "struct passwd" for
them, that contains generic fallback data. That's easy to do in an NSS
module, and the records can be safely synthesized on-the-fly. With
that you basically take ownership of an UID range for sssd fully, and
can be sure that nothing else will invade it. Neither systemd, nor
adduser, nor anything else.

When a user is actually allocated to one of those UIDs you then
replace the reserved entry with a real one. (And flush nscd, if you
care about nscd. Ideally of course nscd wouldn't require that and
accept a TTL value from NSS modules the same way it accepts them for
host lookups, so that the synthetic records could carry a TTL of zero,
so that there's no need to every flush any caches explicitly).

> > 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.

Well, it could, you just need to take the UIDs, see above.

> >  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).

Well, sure, it would be great if we could assign ranges for exclusive
ownership to specific programs, but even then it would be wise to be
defensive, and check NSS before we take a UID — and to do that
race-freely there kinda needs to be a lock file.

There's also the big problem that UID space is scarce. In containers
you usually don't get more than 64K UIDs (so that you can have 2^16
for each container, and 2^16-1 at max, so that you use the full 2^32
UID space). And in those 64K space is scarce, as 1000…60000 is already
all taken by classic adduser. Which only leaves 60000…65533 for
particular applications. 5.5K is not that much left.

With systemd's dynamic users we took "soft" possession of the range
61184…65519. "Soft" because we are defensive if somebody else
allocated from the same range, as we cannot claim sole ownership of
this. And from reports we got that's kinda necessary as UNIX has no
rules in this area and hence existing bigger university installations
used the full 64K range basically without any reservations.

Hence, yes, I'd love if we'd could assign exclusive owenership of
specific UID ranges to specific apps, but that's probably too late
now...

But anyway, I figure you can avoid taking any externally visible locks
if you don#t want to, as long as you reserve the full UID space you
want exclusive ownership for with the suggested synthetic reservation
user entries. As long as all UIDs you took possesion of never show up
"un-unowned" there's no need to take a lock anywhere, as long as you
internally instantly switch over from "reserved" to "taken" and back.

> > 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.

So, the problem with using NSS as reservation database for large UID
ranges is efficiency: if you want to allocate 64K in one go, you'd in
theory have to do getpwuid() on every single UID in it before deciding
to own it. Hence, what I was looking for was that we can say that one
would only have to check all UID where ((uid & 0xFFFF) in [0 … 65535])
or so, i.e. only the first and last UID in each 64K subrange of the
range allocate...

> 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.

For both dynamic users and nspawn user ranges we so far were defensive
and ordered us to the end of the NSS module list, leaving other
modules precedence.

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




[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