Racer X wrote:
> If I'm understanding correctly what you want to do, which is include
> separate binaries for each UID configuration, at some point it's going to
> make your distribution ridiculously big. And besides that, there's STILL
> no guarantee that the package will work on every distribution unless you
> account for every possible permutation of the UID space. It also fails to
> account for the usernames necessary being taken. Yes, qmail is an unlikely
> choice, but it's still possible that it's already present on the system.
>
> I think it would be really nice if Red Hat could guarantee a certain subset
> of the UID space available to packages like this that need predefined UIDs.
> Interactive users already start at 500 I believe, so most anything under
> 500 is fair game to use. Obviously some of it might be in use, so perhaps
> it could be allocated something like this:
>
> 0-99: "Essential" accounts (root, bin, daemon)
> 100-299: Program accounts that don't have UIDs compiled in (apache,
> postgres, ftp) and can be assigned UIDs at install or run time
> 300-499: Program accounts that DO have UIDs compiled in (qmail)
>
> The space from 300-499 would be managed by Red Hat. Application developers
> who need this could register a subset of the UID space, which would prevent
> conflicts on installation since no one would use this space unless they had
> registered it.
We already use 100-999 for internal functions, local daemons, staff users, etc.
Regular users begin at 1000. The range 100-999 can also be used for other
things like qmail, but the allocation of a number has to take place in an
administrative way to ensure that the same number is used across all machines
in our network. Having an install script find an empty UID and making use of
it will cause problems no matter what the number is, unless it can correctly
reserve that number on every machine. But it would be best that qmail get the
same UID on every machine it's install on (and nothing gets that number on the
other machines).
> This is probably not the best solution but it's a start. Linux shared
> libraries were all registered with a central source before the move to ELF,
> and that worked reasonably well. In addition, the number of programs that
> really require compiled-in UIDs is pretty small, so the registration
> probably wouldn't be that big a deal.
It's kinda late to expand centrally registered UIDs beyond the traditional
0-99. People already use 100 and up.
I must question why UIDs, or any system specific configuration parameters for
that matter, need to be compiled in to a program. A standard starting config
file in /etc could fill in all other info. The program reading that file can
then be pedantic and make sure the uid/gid of the file and /etc itself is root
and permissions have not been compromized before it trusts what's in there.
If a program really MUST have a UID compiled in, the administrator will need
to choose it if there is already administrative policy in effect that can be
in conflict. I had no problem with compiling qmail because I could pick these.
OTOH, maybe those who would install a pre-compiled binary are not the ones who
would be doing any universally managed UID numbers. While I do like having
RPMs from Red Hat to quickly install binaries, Red Hat is not the only system
I use.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
