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
