User id allocation and fedora-usermgmt

[David Lutterkort]

On Thu, 2006-03-02 at 21:50 +0100, Enrico Scholz wrote:
> dlutter at redhat.com (David Lutterkort) writes:
> > 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.

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.

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

> > (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. 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; but before we can have this discussion, we
would need an example how it should be changed witha more detailed
allocation policy.

> * 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; there is nothing to
keep a package in FC to appear that will clash with a uid from FE, for
example. As of now, it's not even documented what we want a good citizen
to do when they package and need a static uid for their package.

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

Package removal leaves other stuff around, like logfiles, which is
exactly the reason why you say that reusing uid's is a bad idea
(http://www.fedoraproject.org/wiki/PackageDynamicUserCreationConsideredBad)

> > (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.

That was unclear: dynamic uid allocation erases that benefit. A
do-not-erase-users rule doesn't play into this.

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

Yep. And not much beyond that.

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

Thanks for clarifying that.

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

I think they just wrote up what people were already doing across various
distros. I don't think that narrowing the range of dynamically allocated
uid's to, say, 50 or 100 uid's somewhere in between 200-499 and using
the rest for static purposes would be a violation of the LSB, at least
not in spirit. What people really care about is that when they run
'useradd -r' w/o a fixed uid, that they get a uid in that range. Where
in that range, they don't care, otherwise they would have specified a
uid.

David