User id allocation and fedora-usermgmt

[Enrico Scholz]

dlutter at redhat.com (David Lutterkort) writes:

>> >         UID     For use by/managed by
>> >         0-199   Fedora Core, FC steering committee
>> >         200-299 reserved for future allocation
>> >         300-399 Fedora Extras, FeSCo
>> >         400-499 reserved for future allocation
>> 
>> not possible; accordingly FHS, these ranges are available for free use
>> and must not be assigned statically. 
>
> Actually, that's a very loose paraphrasing of what the LSB (not FHS)
> says[1]:
>
>         The system User IDs from 0 to 99 should be statically allocated
>         by the system, and shall not be created by applications.
>
>         The system User IDs from 100 to 499 should be reserved for
>         dynamic allocation by system administrators and post install
>         scripts using useradd.
>
> This is pretty vague, as far as standards go,

I think it is pretty clear... an LSB compliant package should not assign
a static uid in the 100..499 range. Only 0..99 is available for static
uids.


> and clearly, having only 100 user id's for statically allocated users
> is not practical

agreed. But this rule is originated >10 years ago when people thought
there would be no need for more than 100 system users. It is far too
late to change it now...


> (FC itself already uses more than 100 system users)

Are you really sure? At least FC4 should be below this mark (around 80
users, afair).


>> They might be already in use in existing systems, and a static
>> assignment in future FE packages WILL create conflicts.
>
> Absolutely; though I don't see how fedora-usermgmt addresses that
> issue.

It addresses this issue by:

* being LSB compliant (dynamic allocation) in the default (unconfigured)
  case

* allowing administrators who do not want the mess of inconsistent uids
  to assign predictable uids which are identically at each rpm run and
  on every system


> This seems like an argument for always allocating uid's dynamically
> for FE system accounts, and changing the packaging guidelines so that
> packages will not remove users

Not removing uids violates my idea of packaging (package removal should
restore the system to the state before package installation)


> (which fixes the security risk from reused uid's) It would also erase
> the one big benefit of statically allocated uid's: easy correpsondance
> of users across machines in a network for things like NFS filesystems.

I do not see how a do-not-erase-users rule would guarantee identical
uids on different machines.


>> The fact is, that you will not find a free range for new static uid. The
>> only possible range for static uids is 0-99 which is reserved for Core
>> already.
>
> I think this is mainly because there has never been a clear guideline
> on what to do.

When something is clear, then, that 0..99 is reserved for Fedora Core.


>> > For Fedora Extras, user id's would be tracked as they are right now
>> > at http://fedoraproject.org/wiki/Packaging/UserRegistry (with all
>> > uid/gid's bumped up by 300) and new uid's/gid's would be allocated
>> > during package review from the FE range 300-399.
>
> It seems that that page
> http://fedoraproject.org/wiki/Packaging/UserCreation is only a
> recommendation, not a requirement for package review. Could you change
> the page to clearly state that it's not a packaging requirement?

ok, should be done


> I think it's pretty confusing as it is right now.

afaik, this page was never referred from some packaging guideline.


>> I am in doubt that we will stay below 100 users...
>
> Absolutely. But for the time being, it's enough; once we approach the
> 100 uid's we would have to either allocate more uid's or think of
> something else.

LSB people had probably the same idea when they created the rules about
the uid ranges years ago...



Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060302/8f27f9e4/attachment.sig>