Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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@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
Attachment:
pgp7gy2aEt4Sj.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
