[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[Paul Howarth]

On Tue, 2007-05-01 at 10:10 -0400, Ed Hill wrote:
> On Tue, 01 May 2007 08:16:16 +0100 Paul Howarth wrote:
> 
> > Ed Hill wrote:
> > > On Mon, 30 Apr 2007 21:46:04 +0200 Axel Thimm wrote:
> > >> Personally I prefer banning multilib in rpm for good and if that
> > >> would be best done by using chroot solutions, I'm all for it. The
> > >> multilib implementation within rpm magic just isn't scaling and
> > >> produces more bugs on the way than we can fix.
> 
> [snip]
> 
> > > It just seems to me that chroots are probably a lot less usable than
> > > binaries placed in {,/usr}/{,s}bin64 or similar.
> > 
> > chroots and SELinux don't play nicely together at the moment either. 
> > You'd need to replicate the entire set of default contexts into each
> > chroot.
> 
> 
> So is it fair to say that chroots are too problematic for anyone other
> than "extremely knowledgeable users" to take advantage of them?

>From an SELinux point of view, probably yes at the moment. Consider the
two chroot environments I currently use:

1. bind-chroot. The selinux-policy replicates the default contents for
everything under /var/named/chroot:

# semanage fcontext -l | grep chroot
/var/named/chroot(/.*)?                            all files
system_u:object_r:named_conf_t:s0 
/var/named/chroot/etc(/.*)?                        all files
system_u:object_r:named_conf_t:s0 
/var/named/chroot/var/tmp(/.*)?                    all files
system_u:object_r:named_cache_t:s0 
/var/named/chroot/var/named(/.*)?                  all files
system_u:object_r:named_zone_t:s0 
/var/named/chroot/var/run/dbus(/.*)?               all files
system_u:object_r:system_dbusd_var_run_t:s0 
/var/named/chroot/var/run/named.*                  all files
system_u:object_r:named_var_run_t:s0 
/var/named/chroot/var/named/data(/.*)?             all files
system_u:object_r:named_cache_t:s0 
/var/named/chroot/var/named/slaves(/.*)?           all files
system_u:object_r:named_cache_t:s0 
/var/named/chroot/dev/null                         character device
system_u:object_r:null_device_t:s0 
/var/named/chroot/dev/zero                         character device
system_u:object_r:zero_device_t:s0 
/var/named/chroot/dev/random                       character device
system_u:object_r:random_device_t:s0 
/var/named/chroot/etc/rndc\.key                    regular file
system_u:object_r:dnssec_t:s0 
/var/named/chroot/var/named/named\.ca              regular file
system_u:object_r:named_conf_t:s0 

This is manageable because there are only a very limited number of types
of files living in this chroot, and only one application using them.

2. mock

This is a much more complicated issue because just about anything might
need to run as part of a package build within a mock chroot, and the
path to the chroot includes an arbitrary directory name, albeit fixed to
be within /var/lib/mock. The current method for using mock with SELinux
enforcing effectively runs the entire build process unconfined by
SELinux, since it would be too complicated to get the file contexts set
up "properly".

A possible solution to this could involve rpm looking up the file
contexts for files it's about to install based on their pathname within
the chroot rather than their full hierarchical pathname from the real
root directory; I don't know enough about rpm internals to know if
that's viable though. That would get the initial contexts right but
there would still be problems if the system was relabelled though,
unless the relabelling process could be made aware of the chroots and
treat them accordingly.

Paul.