Re: strawman proposal: homed directories for users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 8, 2024 at 12:35 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
>
> On Di, 08.10.24 12:23, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote:
>
> > On Tue, Oct 8, 2024 at 12:19 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
> > >
> > > On Di, 08.10.24 18:07, Fedora Development ML (devel@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> > >
> > > > Am 08.10.24 um 17:32 schrieb Lennart Poettering:
> > > > > For example, I am fundamentally opposed to the model
> > > > > these systems generally pursue of turning UID numbers into centrally,
> > > > > organization-wide managed concepts.
> > > > Wait a second, some organization have more than 70k people (and in this
> > > > day and age, they all require their own accounts) and UIDs are (on
> > > > Linux) 16bit numbers (which means a max of 65536 possible values).
> > >
> > > uid_t is 32bit.
> > >
> > > See https://systemd.io/UIDS-GIDS for our (i.e. systemd's) take on UID
> > > ranges and how much is actually available from the 32bit for what.
> > >
> > > (Note that this document does not take IPA world into account, which
> > > doesn't really subscribe to the idea that projects should allocate
> > > from specific UID subranges only, and wants to own the whole range
> > > instead. Sad.)
> >
> > I'm not sure where you got that from...
> >
> > "By default, an IdM ID range is automatically assigned during the IdM
> > server installation. The ipa-server-install command randomly selects
> > and assigns a range of 200,000 IDs from a total of 10,000 possible
> > ranges. Selecting a random range in this way significantly reduces the
> > probability of conflicting IDs in case you decide to merge two
> > separate IdM domains in the future."
> >
> > You can select this range explicitly when setting up the domain and
> > you can add more 200k ranges later (though the first one you create is
> > immutable).
> >
> > [1] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/adjusting-id-ranges-manually_configuring-and-managing-idm#automatic-id-ranges-assignment_adjusting-id-ranges-manually
>
> Comments like this from @abbra:
>
> https://github.com/systemd/systemd/pull/30846#issuecomment-1884526052
>
> Apparently the ranges are always configurable in IPA, and which ranges
> are used is stored in LDAP. This makes the logic systematically
> incompatible with various low-level uses where we need to classify
> UIDs in a very basic way, but cannot possibly consult any external
> database, IPC, or even network stuff.
>
> It would all be very easy if IPA would just stick to one range of
> UIDs, and allocate from that, but apparently IPA really wants this to
> be entirely configurable as I understand.
>

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.

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux