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