On Thu, 2018-12-06 at 17:49 +0100, Lennart Poettering wrote: > On Do, 06.12.18 11:25, Simo Sorce (s...@redhat.com) 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
