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.) 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). 2. When picking a UID we check with NSS first if the UID is already taken. 3. When picking a UID we also check if any IPC object is already owned by the UID. 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. 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. But I still think the best database for such allocation should be NSS itself, right now. What would be great if we'd at least agree on a better lock file though, maybe in /run. 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. 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
