On Sat, 2007-03-10 at 16:15 +0100, Enrico Scholz wrote: > 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 Again its a local policy, bad planning can hose this up as well and you may have 2 different spaces on 2 machines. This makes the whole mechanism simply completely useless. You do not have a real fixed uid, nor a dynamically allocated uid, just the worst of both. > > 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) Should !? > 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 Oh nice very useful, so now we trade a dynamic uid with a possibly failed package installation ... very useful!! > > 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 The user space window is defined as anything > 500 > * teach the tool which creates the users that the window is tabooed This is exactly the same thing as increasing the reserved fixed space to 200 or 300, and that _is_ a solution! Yours is a bad hack. Simo. -- 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
