On Fri, Jun 15, 2007 at 08:50:58AM -0500, Tom spot Callaway wrote:
On Fri, 2007-06-15 at 09:38 +0200, Axel Thimm wrote:
> Like Bill wrote, have useradd -r bail out if the uid is outside the
> range.
>
> But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones,
> 500-... for users. If you touch this (e.g. extend to 1000) you break a
> lot of stuff like user homes.
I'm not opposed to this. Now, someone needs to figure out how.
> I vote for Ville's draft with a plea to the useradd maintainer to make
> useradd -r fail if the result is that the uid/gid is not in the system
> range. And also have the %pre script miseably fail to wake up the
> sysadmin ("Hugh, we have a user called Gopher?").
The last part is not going to work. %pre can never fail, it will break a
transaction in unfortunate ways. Useradd can fail, but we need to
silently mask it. Output from %pre is not useful in a kickstart
transaction.
Every silent recovery will bear security issues. Either the files get
owned by a user, or by root, both are not acceptable imo.
So we need to have this package installation fail. The issue with
depsolvers messing up a transaction needs to fixed irrespective of
this particular case.
And I think the fix is also rather simple (no, not volunteering!):
smart for example has a mode to install/remove package by package
instead of installing all packages and then uninstalling the old
ones. Whne something fails in this mode be it %pre or %post it only
messes up exactly zero to one packages (%pre zero, %post one).
An alternative route would be for yum to see that in a transaction
package $N failed and instead of bailing out directly after that to
run the clenup part for packages 1-($N-1). This also doesn't sound
like impossible to do (still not volunteering ;).
So it's a bug that looks fixable with sane effort and we should not
need to obfuscate specfiles or drop features like %pre exiting due to
that.
--
Axel.Thimm at
ATrpms.net