with or without fedora-usermgmt

Axel Thimm Axel.Thimm at ATrpms.net
Fri Mar 16 01:08:18 UTC 2007


On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote:
> Peter Vrabec (pvrabec at redhat.com) said: 
> > Don't you think somebody should make some decision here:
> > http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
> > - flame, but possible pros and cons can be find there
> > My opinion is not to use fedora-usermgmt.
> 
> My proposal is to use 100-499 for static as well, and just do static
> registrations for everything - it's simpler. It can be combined with
> making dynamic system IDs  go from 499 down as well.

I don't think that most packages need static uids. And if there are
really some that would benefit we still have 40% of the static uid
space *empty*.

So there really is no problem that had to be `fixed' in the first
place.

Extending the static uid range *now* would be wrong, because we would
have to introduce "would-like-to have-static-uid-at-101-but-I-still-
have-to-deal-with-getting-a-dynamical-random-uid-if-101-has-been-taken"
giving us the worst combination: uid ranges labeled as fixed that the
application(s) still cannot assume to be really fixed, so there is no
gain today in doing so.

Instead the patch that Peter wrote to make dynamic uid/gid allocation
top-down, e.g. from 499 backwards, will allow us to revisit the issue
in a couple of years when the static uids really get scarce (we
managed a decade with occupying only 60%), and when the probability of
having dynamic uids/gids at the lower end (100 upwards) will be much
lower than today. In the meantime we can open a discussion with the
LSB about rearranging the uid/gid space in future specs.

If that ain't strategic planning ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070316/71f0aff7/attachment.sig>


More information about the fedora-devel-list mailing list