On Fri, 2024-10-11 at 09:43 +0200, Lennart Poettering wrote: > On Do, 10.10.24 17:22, Simo Sorce (simo@xxxxxxxxxx) wrote: > > > On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote: > > > On Mi, 09.10.24 11:12, Simo Sorce (simo@xxxxxxxxxx) wrote: > > > > > > > > > > > > > This was again a reference to the fact that IPA folks aren't willing > > > to restrict their allocations to some reasonable UID range, as > > > mentoined elsewhere in this thread. > > > > > > > Can you stop with this please? > > This is absolutely not true is starting to become really annoying and > > tiresome, let's please not do that. > > > > It has been explained to you by me (and in person years ago) and others > > multiple times that FreeIPA has a fixed range it picks from, but to > > allow *multiple* domains to interoperate it picks a subrange from that > > big one fixed range, which is high up in the "millions* (I forget the > > exact range but I think 1M-2M). > > Stephen said in this very thread the IPA range is 10K…2010K. > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/IO33GOYAHHTRL7LIGXW5WJQNIUYW2WND/ > > So what is it now? > > The difference is pretty relevant, because 10K means 16bit range, and > coverage of the special Linux UIDs 65535, 65534. > > > As an example this is my personal domain user which I installed ages > > ago and has this record: > > > > $ getent passwd simo > > simo:*:1649000003:1649000003:Simo Sorce:/home/simo:/bin/bash > > > > As you can see there is no conflict with any reserved ID, please get > > your facts straight. > > Well, you guys are contradicting each other! > > Can you please tell me the accurate fixed range that IPA allocates > from? I heard various things now: > > 10K…2010K (Stephen) > 1M…2M (you, above) > 200K…2G (somewhere in the IPA docs) > > What is it now? Alexander Bokovoy gave you a document more than once over the years. The total range IPA picks from by default is 200K-2G, from which an IPA domain picks a random 200K range by default and sticks to it for the life of the domain. I just said in the millions, because that is generally what happens, I wasn't trying to be exact, because it doesn't matter, it is clearly outside of the danger zone, and for the purpose of the discussion it didn't matter to be exact. > > if 1M…2M is right I'd be quite happy actually, that's a managable > range, I'd be happy make systemd respect that. Alas, I think it's not > actually accurate, is it? > > 10K…2010K would be highly problematic, because it overlaps with said > spcial Linux UIDs, and is 16bit and so on. > > 200K…2G would be problematic too, for example it conflicts with where > local subuid/subgid allocates from (524288…600100000). Local subuid/subgid things came a decade+ after FreeIPA had established ranges, and as you said it is a bad idea to use subuids, I agree with that, so I do not care that we conflict. Look a 32bit UID range is just ridiculous, it *cannot* work for everybody, so conflicts will just happens if you take many unmanaged machines in aggregate. In domains that need conflict free IDs administrator have to be involved and have to make reasonable choices and carve out pieces where there is a conflict. This is an unsolvable problem with the way the Linux kernel manages IDs, The solution exist in the industry and it is what Microsoft calls SIDs, if we had that we would be reserving special domain SID spaces for various special purposes and leave others for actual real user domain IDs. Unfortunately nobody wants to introduce such a concept in the Linux kernel, so we'll live with conflicts for the forseable future. Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- _______________________________________________ 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