Fedora User Management (revisited)

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Sat Mar 10 15:15:39 UTC 2007


Axel Thimm <Axel.Thimm at ATrpms.net> writes:

>> Argh, you removed the context. Because fedora-usermgmt can't solve
>> the issue of fixed uid? And because the smei-static, but almost
>> always random method of fedora-usermgmt would be of no help?
>
> Let me clarify: It's not random as per a random number generator
> chosen, but random as in not-predictable. Maybe non-deterministic and
> non-predictable would had been the better wording, let's not play
> games with words, the context was unambiguous (which is why you
> cutting the context is A Bad Thing):
>
> # fedora-useradd 42 -r iwant42
> # fedora-useradd 666 -r iwant666
> # id -u iwant42; id -u iwant666
> 103
> 104

Fedora-usermgmt was not configured by you and I can not preconfigure it
because there is no free room for the uids. My MUA would not send mails
before I set correct values and my /home would not be mounted before I
add corresponding /etc/fstab entries either.

So I think, a system should be configured before things are evaluated
which are only available after configuration.


When you would:

1. look for a free uid space in your environment (e.g. 63000-64000)
2. make this know to fedora-usermgmt:
   | # echo 63000 >/etc/fedora/usermgmt/baseuid
   | # echo 63000 >/etc/fedora/usermgmt/basegid
3. enable the predictable-mode of fedora-usermgmt
   | # /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils


Then, you will get predictable user <-> uid mappings:

| $ for i in athen apadana db mailhost mail-filter www-cache; do \
|   ssh root@$i 'export LANG=C; fedora-useradd 1500 -r foobar; id foobar; fedora-userdel foobar'; done
| uid=64500(foobar) gid=64500(foobar) groups=64500(foobar)
| uid=64500(foobar) gid=64500(foobar) groups=64500(foobar)
| uid=64500(foobar) gid=64500(foobar) groups=64500(foobar)
| uid=64500(foobar) gid=64500(foobar) groups=64500(foobar)
| uid=64500(foobar) gid=64500(foobar) groups=64500(foobar)
| uid=64500(foobar) gid=64500(foobar) groups=64500(foobar)


Plain useradd will give unpredictable results

| $ for i in athen apadana db mailhost mail-filter www-cache; do \
|   ssh root@$i 'export LANG=C; useradd -r foobar; id foobar; userdel foobar'; done
| uid=102(foobar) gid=103(foobar) groups=103(foobar)
| uid=100(foobar) gid=101(foobar) groups=101(foobar)
| uid=100(foobar) gid=101(foobar) groups=101(foobar)
| uid=101(foobar) gid=102(foobar) groups=102(foobar)
| uid=100(foobar) gid=101(foobar) groups=101(foobar)
| uid=100(foobar) gid=101(foobar) groups=101(foobar)

(I admit that the test was manipulated by me by adding some users on
'athen' and 'mailhost' ;)


> BTW is there an upper limit to what you register with fedora-useradd?

Around 500-1000; for my local system I use a policy (window for service
uids) of

|  Service (Fedora RPM-package)  63000-63999
|  Service (local RPM-package)   64000-64999 


> What happens if the package wants to register into the user reserved
> space?

Should not happen resp. detected during the review (cry loudly when
hint-id is out of order)

Else, when fedora-usermgmt tries to override an existing user, it will
fail:

| $ ssh root at athen "LANG=C fedora-useradd -62495 -r foobar"
| useradd: UID 505 is not unique


> Is there any check that my user Bob won't suddenly become the master
> of the web server or any other accidentally overlapping daemon?

ok; when the assigned window is in the middle of the normal user space,
this will be a problem indeed. Solutions:

 * choose a window above UID_MAX (/etc/login.defs) resp. adapt this
   value. ditto for GID_MAX

 * teach the tool which creates the users that the window is tabooed





Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070310/b095e7b7/attachment.sig>


More information about the Fedora-maintainers mailing list