On Thu, Oct 10, 2024 at 5:23 PM 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). > > 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. > > Now clearly older Unixes are dead, and NFS has finally come out of the > stone age and should be able to handle 32 bit ids everywhere, so there > is less need to allocate in a low range, but UIDs in long lived > organizations are really hard to change. At RH my Corporate uid is in > the low range for historical reasons (there have been at least two > migration through NIS and then LDAP servers and finally IPA since I > joined a couple of eons ago), and IPA serves it and it is fine. > > Just to be clear, IPA came out a more than a decade before systemd > started looking into any of this, and it was a more than decade after > Samba had already dealt with UID mapping in AD domains. > Ranges are always local and it is unlikely a system will need to use > two competing allocation technologies, so this is not a big deal in any > case, but at least please lets try to get facts rights and not try to > cast some kind of blame where there is none to cast. > > What is reasonable or not depends on the historical circumstances of > development and deployment, and can be changed as needed, you can > simply open an issue on the freeipa project and discuss there the pros > and cons, if the current defaults are not ok for whatever reason, > nobody will bite you. > > The reason why historically IPA *had to* allow to use a range below 65k > is that we had compatibility requirements with older NFS and other Unix > systems that could handle no more than 65535 ids (remember this project > is now 17 years old and derive a lot from a project that is 30+ years > old), and a systems of that era. > > > Let me emphasize again, right now, the UID range IPA takes possession > > of collides on Fedora currently with: > > > > 1. classic UNIX users created via /etc/passwd adduser, > > i.e. shadow-utils and stuff. As mentioned elsewhre, logind.defs > > says this range goes to 60K, but IPA already starts before that. > > 2. special Linux UIDs 65535, 65534 > > 2. dynamic service users allocated via DynamicUser=1 in systemd unit > > files > > 3. systemd-homed users > > > > (and more...) > > Yeah this is simply misleading, FreeIPA *allows* an administrator to > overlap those ranges for legacy compatibility reasons, but it has never > been the default. > Some of this is my fault. I responded earlier in the thread and cited (incorrectly) that the defaults covered a range from 10,000 - 2,010,000. My memory was faulty and I got the wrong offset for the low-end. Then I got sick yesterday and the conversation ran ahead without me being able to correct that misstatement. I can't seem to dig up the actual lower bound, but I think it's more like a range of 200,000 - 2,200,000 than my original statement. > > > > > Can you configure autologin for those uses cases (like kiosks or a home > > > > > entertainment system) where that makes sense to do ? > > > > > > > > No you cannot, the security model relies on unlock keys to be provided > > > > before the home directory is accessible. It's a strength of the model, > > > > not a weakness, that user data is actually protected by the provided > > > > user authentication credentials. > > > > > > So that is another use case that you need to know in advance before > > > installation, how hard it is to "convert" the system if you made the > > > incorrect choice? > > > > You can just copy out the files/chown them and add a classic UNIX user > > record if you wish. > > Ok so this requires a highly skilled person, a regular person would > have to create a new user from the UI (assuming it gives the option to > specify what kind of home you get) and somehow copy data over from one > account to the other, which is additional work for mgmt tools. > > > > > As I understand the IPA/sssd model is a lot more traditional there, > > > > and does not consider the user's data as something to protect? I'd > > > > call that highly problematic, but I guess it's from a different time. > > > > > > It is not from a different time, it is from a different use case. > > > In general you expect full disk encryption on corporate/centrally > > > managed machines, not per-user encryption, unless you can escrow per- > > > user encryption credentials, which I do not think systemd-homed is well > > > positioned to do currently. > > > > I am pretty sure you want both, as mentioned: encryption of system > > data to the TPM, and user data to a personal credential. > > For corporate machines FDE with a single escrow key is more cost > effective so they prefer to do it that way, but I am agnostic here, > each one can evaluate their threat scenario and choose what works best. > > The problem for Fedora is figuring out what is a reasonable default, > and how difficult it is to provide multiple options if that is where > Fedora wants to go, offering exclusively homed based setups is probably > not sufficient. > > 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 -- _______________________________________________ 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
