On Di, 08.10.24 12:46, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote: > I suspect you're talking past one another here; in practice, IPA has a > random set of ID ranges that (IIRC) essentially owns the ID space of > 10,000 - 2,010,000. (It's possible for the installer to set an > arbitrary range outside that, but it's a custom choice). So you could > probably reserve the IDs above 20,010,000 for homed in that situation. Uh, that seems like a problematic choice for IPA. First of all within that range is the UID 65534, i.e. the linux nobody/overflow/unmapped UID. You should not delegate this UID for any users. Moreover, 65535 (the -1 value in 16bit) is special, as it indicates "don't change" in various legacy APIs, old file systems and so on. Newer apis generally use 4294967295 for that (i.e. -1 in 32bit), but for compat 65535 should be avoided to. If you so will, the uids 0, 65534, 65535, 4294967295 all have some special meaning to Linux, and should not be used for regular users. Hence it's highly problematic if IPA just delegates 65534 or 65535 to its regular users, as you appear to suggest. But there's more: container managers typically do not delegate more than 64K UIDs to containers (that's what nspawn does, and as I understand, other container managers map even less space by default). Yes, you can delegate more if you do extra work, but it's not what happens by default. This means, UIDs < 2^16 are more "valuable" than those >= 2^16. In particular for stuff that shall "just work" inside of containers it's kinda relevant to stick to ranges < 2^16. (systemd-homed's local UID allocations qualify as that) With your definitions above you basically take most of that range for IPA as private property, and I think that's just not OK, it's leaves no space for anyone else in the 16bit range really (under the assumption that 1000…60000 are for classic /etc/passwd users, which is what Fedora's login.defs dictates). (BTW: talking about login.defs: if IPA wants to take possession from UID range 10000 on, you are conflicting with Fedora's login.defs definition which assigns the range 1000…60000 to regular users, i.e. /etc/passwd) Hence, what I'd like to ask IPA to do do is first of all stay away from the 65534 + 65535 UIDs, that's just a major bug if you ask me. I'd then like IPA to say away from the regular user range declared in login.defs, i.e. UIDs < 60K. But also: leave some room in the 16bit range, outside of the regular user range for other users. My suggestion: change IPA to allocate from the range 65536…524287 range or so. Or alternatively from 1879048192…2147483647, which would mean it wouldn't conflict with anything else anymore. I understand that existing IPA deployments ignore all this, and that's bad but hard to change. But at the very least, maybe for future installations suggest better ranges. We documented all our UID assignments and their reasons here: https://systemd.io/UIDS-GIDS/ It would be very wise if IPA maintained a similar document with its assignments, and similar considerations regarding the special UID ranges and everything. Double assignments like the login.defs or overflow UID stuff really should be avoided, and good documentation helps for that. I'd also be happy to update the UID/GID table on aforementioned systemd documentation and delegate some range explicitly to IPA (or IPA-like usecases) there, but for that I'd need some committment that at least future IPA installations would honour it. Lennart -- Lennart Poettering, Berlin -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
