On Tue, Nov 16, 2004 at 12:53:35PM -0500, Jeff Johnson wrote: > On Tue, Nov 16, 2004 at 01:46:14PM +0100, Axel Thimm wrote: > > when trying to setup FC2 chroots on FC3 hosts I get a lot of > > selinux errors. The filesystem in question has the following > > (default) security contexts in place: > > > > root:object_r:default_t > > > > (fs is mounted beneath /data in permissive/targeted mode) > > > > The errors look like the following: > > cracklib-dicts ################################################## > > +error: unpacking of archive failed on file /usr/lib64/cracklib_dict.hwm: cpio: lsetfilecon failed - Inappropriate ioctl for device > > sed ################################################## > > libattr ################################################## > > libacl ################################################## > > coreutils ################################################## > > +error: unpacking of archive failed on file /usr/sbin/chroot: cpio: lsetfilecon failed - Inappropriate ioctl for device > > > > It looks like these FC2 packages have stored security contexts in the > > archive and rpm cannot recreate them. > > > > a) Why cannot rpm recreate the security contexts? Do I need some > > special policies to allow setting up chroots into > > /some/path/to/chroot? > > > > Look at libselinux if you want to know why the failure, and > what to do about it. rpm supplies logistical mechanism to set > file contexts only, reading the file context regexes, calling > the function in libeselinux, and duly reports information > at hand on failure. Diagnosing selinux failures is a deep > context way beyond what is implemented in rpm. OK, but from rpm's POV this is an error that happened when it attempted to apply file contexts stored in the rpm onto the filesystem (after copying the files from the cpio archive). Is that correct? > > b) Why does this only occur in FC2 and not FC3 chroots? Don't FC3 > > packages contain security contexts anymore (namely coreutils and > > cracklib-dicts)? Perhaps because of the above? > > > > The problem (and fix) will require diagnosis deeper than "fails > in FC2 chroots, works in FC3 chroots". The starting point is > invariably looking at AVC messages to identify the failure, > and then correcting the contexts and/or policy to address > the failure. I'd be glad if there were any messages more than what rpm delivers. selinux is permissive and the policy is targeted, so this is not an access control failure. BTW turning selinux completely off makes the error go away. > > > c) Should rpm handle these failures more gracefully, i.e. have a > > switch to turn them into warnings? > > > > SELinux is not optional at the application level, nor can mandatory > access controls be finessed with a "switch" in rpm. I was thinking of a switch that turns off setting file contexts at rpm install time. rpm could o try to set the file contexts and if it fails it either returns an error and bails out (like the current situation, should remain the default) o ignore internal file contexts with --nofscontext o convert error to warnings with --warnfscontext Anyway my chroots seem to work again after switching off selinux, so I'm happy again ;) -- Axel.Thimm at ATrpms.net
Attachment:
pgp1NAcHT9old.pgp
Description: PGP signature
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
