On Чцв, 10 кас 2024, Stephen Gallagher wrote:
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.
When we had our previous round of discussions with Lennart, I created a
document that outlines FreeIPA identity mapping details. It is published
at https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html.
Perhaps, it is still not enough to explain the field we are dealing
with...
> > > > 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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
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
