mount --bind and autorelabel versus restorecon

[Per Sjoholm]

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 ?