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. > > > > 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
