-----BEGIN PGP SIGNED MESSAGE-----
On 09/16/2012 09:00 PM, Tom London wrote:
On Mon, Aug 20, 2012 at 2:59 AM, Daniel J Walsh
On 08/19/2012 04:24 PM, Tom London wrote:
>>> On Tue, Aug 14, 2012 at 2:21 PM, Dominick Grift
>>> <dominick.grift(a)gmail.com> wrote:
>>>> You might want to check out the semanage --equiv option. (man
>>>> That basically allows you to alias existing file context
>>>> heres an example from man semanage:
>>>> For home directories under top level directory, for example
>>>> /disk6/home, execute the following commands. # semanage fcontext -a
>>>> -t home_root_t "/disk6" # semanage fcontext -a -e /home
>>>> # restorecon -R -v /disk6
>>>> so in your case you might want to make /data equivalent to / or
>>>> semanage fcontext -a -e / /data restorecon -R -v -F /data
>>>> That should label /data root_t, /data/var var_t, /data/var/lib
>>>> var_lib_t etc.
>>>> just as if it was your main file system.
>>> So this sounds exactly what i would like to do with my Luks encrytped
>>> USB back up drive.
>>> Unfortunately, I'm stumbling across the fact that the drive is
>>> 'automagically' mounted (when I login or power it on), and it gets
>>> mounted on /run/media/tbl/Backup1TB:
>>> /dev/mapper/luks-94a9d7d7-f819-4c2c-b735-81bb28db0426 on
>>> /run/media/tbl/Backup1TB type ext4
>>> The 'semanage -e' command spews:
>>> [root@tlondon ~]# semanage fcontext -a -e /
>>> /run/media/tbl/Backup1TB/X200 /sbin/semanage: File spec
>>> /run/media/tbl/Backup1TB/X200 conflicts with equivalency rule '/run
>>> /var/run'; Try adding '/var/run/media/tbl/Backup1TB/X200'
>>> [root@tlondon ~]#
>>> Appears that '/var/run/media' doesn't exist on my system (I
>>> /run and /var/run are not really 'equivalent'?).
>>> This an issue with my system (e.g., do I need an explicit entry in
>>> fstab or some such)? With the scaffolding that deals with /run and
>>> /var/run? Other? Should this work?
>>> Thanks, tom
Yes it is telling you about a double equivalence. systemd guys have
suggested that we reverse the equivalence. since /var/run does not really
exist anymore, they suggested we move to /var/run -> /run rather then what
we currently have /run -> /var/run. My concern with this switch would be
if users/package developers had already added file context for /var/run
So I tried this to work around the 'one-level equivalence detection':
[root@tlondon ~]# mount --bind /run/media/tbl/Backup1TB/X200/ /mnt
[root@tlondon ~]# semanage fcontext -a -t root_t /mnt [root@tlondon ~]#
semanage fcontext -a -e / /mnt [root@tlondon ~]# restorecon -v -R /mnt
restorecon reset /mnt context
reset /mnt/.tcshrc context
restorecon reset /mnt/run context
reset /mnt/enable-unconfined context
restorecon reset /mnt/.lesshst context
<<<<<SNIP>>>>> <<<<<Lots of relabelling
here>>>>> restorecon reset
restorecon reset /mnt/var/cache/jetty context
reset /mnt/var/cache/jetty/temp context
reset /mnt/var/cache/httpd context
reset /mnt/var/cache/httpd/proxy context
I checked a few relabelled files, and the contexts seem correct, for
example: restorecon reset /mnt/usr/share/jetty/bin/jetty.sh context
I should have used something other than '/mnt', of course. And since the
drive is not persistently mounted, I'm thinking of wrapping the 'rsync'
command with 'semanage' commands that temporarily add/delete the mappings.
Am I correct in assuming that the way to do this is (presuming bind mount
the mounted path to '/backup'):
semanage fcontext -a -t root_t /backup semanage fcontext -a -e / /backup
rsync ..... lots of options
semanage fcontext -d -e / /backup semanage fcontext -d -t root_t /backup
That seem right?
I would figure
/backup/run/blah or /backup/usr/lib64 might be labeled differently then /run
Since only one substitution would happen. You would really need to do all of
the substitutions again.
/backup/run == /var/run
/backup/usr/lib64 == /usr/lib
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
-----END PGP SIGNATURE-----