On Tue, 2009-02-17 at 20:53 +0100, Per Sjoholm wrote: > > Stephen Smalley wrote: > > On Tue, 2009-02-17 at 15:26 +0100, Per Sjoholm wrote: > > > >> There are more than one problem described here and the are connected. > >> One is the basic how to organize data regarding updates, backup and daily task. > >> One is SELinux protection. > >> One is this should NOT be a problem in the first place. > >> (IT was NOT until target/enforing policy) > >> > >> I have systems and try to keep OS and data separated. > >> This makes backup and updating OS easier. > >> SELinux chamges things. > >> Normaly: > >> Partion 1,2 and 3 contain an OS and 4 is an extend partion with my data. > >> Then I can install a new OS and prepare it before changing over. > >> Keeping system running, rebooting into the new version. > >> Reverting to old OS version by a reboot if needed. > >> > >> ONLY OS dependent data(config, deamon ..) is under "/" rest is elsewhere > >> and the physical file system for /dev/sda5 is mounted under /disk_dev/sda5. > >> with a mount --bind parts of /disk_dev/<part>/<subdir> get mounted i the proper place. > >> mount --bind /disk_dev/sda5/projects/A /prj/A > >> the NFS4 exports is an other example > >> > >> Some clients use samba and some NFS parts of the data should be available via httpd, bittorrent. > >> Some of the files are large and can't be duplicated (symlinked)? > >> Most data belongs to A project and the project belongs to a group > >> > >> SELinux > >> Using symlinks or an alias in httpd does not work as components in the path > >> is missing lables as they contain data that ftp,samba or httpd is not ment to read. > >> > > > > You should be able to label those symlinks or directory components with > > a type that is readable by those domains, e.g. public_content_t, or add > > allow rules via a local policy module to allow those domains to > > read/search whatever type is presently on those symlinks or directory > > components. > > > > > >> autorelabel only handles filesystem mounts NOT mount --bind > >> the result of > >> doing a touch /.autorelabel; reboot > >> doing a restorecon -R <path> > >> > >> will differ as autorelable does only see the physical mount. > >> > >> It's possible to construct file context and they will most likely NOT > >> work reliable for both autorelabel and restorecon > >> > > > > If you can't reorganize your actual filesystem layout (e.g using LVM), > > then perhaps the easiest solution here would be to disable labeling of > > the actual file tree under /disk_dev and only use restorecon to label > > the logical file tree. Steps: > > 1) Exclude /disk_dev from relabeling. > > semanage fcontext -a -t "<<none>>" "/disk_dev(/.*)?" > > > > 2) Relabel your logical file tree. > > restorecon -R / > > > > > Sounds good > I will use a /prj/web and mount --bind to create a logical tree > Is there a way of triggering a restorecon -R / if a autorelabel has > occured ? You could modify /etc/rc.sysinit to invoke /sbin/restorecon -R / instead of running /sbin/fixfiles restore, I think. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
