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

Re: User id allocation and fedora-usermgmt

dlutter redhat com (David Lutterkort) writes:

>> >         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.
> What I meant with vague is that the LSB doesn't have any detail on
> the 100 - 499 range; throwing the uid's for packages and what system
> admins do locally into one bucket is just a description of the status
> quo.

It means, that an LSB compliant package should not assign a static uid
in the 100..499 range, and that an uid appearing there can be created
only by 'useradd -r' (without '-u').

>> > 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...
> I agree that it would be hard to change for existing installations; you
> yourself have noticed a need for change in that area and written
> fedora-usermgmt. I am saying that with a clear policy we could improve
> on what the LSB describes there. At the very least, it would clarify how
> the desire for static uid's allocated above 100 can be reconciled with
> the needs of FC/FE.

Static uids above 100 are not possible for LSB compliant packages.

>> > (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).
> /usr/share/doc/setup-2.5.44/uidgid on my FC4 system lists as the highest
> uid (besides nfsnobody) gkrellmd as 101.

gkrellmd is obviously a packaging bug. E.g. an installation sequence of

1. minimal install
2. something, which does 'useradd -r'
3. 'gkrellmd' installation

will break at 3. because 2. created a user with uid 101. It also violates
the LSB ;)

> Which also means that something will have to be done for FC at some
> not-too-distant point in the future.
>> It addresses this issue by:
>> * being LSB compliant (dynamic allocation) in the default (unconfigured)
>>   case
> I think since the LSB describes something that's impractical in reality,
> the LSB should be changed;

Try it; but I have very little hope that LSB can be changed in this point
because there are too much existing installations which use 100..499 for
their own purposes.

> but before we can have this discussion, we would need an example how
> it should be changed witha more detailed allocation policy.

My suggestion would be, to use 500..999 for static system uids. ;)
Debian starts ordinary users already at 1000, now some other distros
have to follow and some administrators have to re-uid their users ;)

>> * 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
> But it doesn't solve the fundamental problem that there is no assurance
> that they map the uid's into a 'safe' uid range;

The 'safe' range must be choosen by the administrator; the administrator
can be sure that uids between 500 and 65533 (and perhaps the extended
32bit range) are available for his purposes. No package should assign a
uid there.

Which range within 500..65533 is safe for semi-static uids assigned by
fedora-usermgmt depends on the local policy.

> there is nothing to keep a package in FC to appear that will clash
> with a uid from FE, for example.

FC is going to become smaller in the future and there should be around
20 free uids below 100. So, FC can stay completely in the 0..99 range.


Attachment: pgpp8HYGe0FRT.pgp
Description: PGP signature

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