Tony Nelson wrote:
At 12:37 PM +0100 6/1/06, Paul Howarth wrote:
Alan M. Evans wrote:
...
In any case, in your reply to the message linked above, you say:
If it was me I'd just bind mount /home/pgsql on /var/lib/pgsql
and there wouldn't be an issue...
And so I wonder: How does bind-mounting help me as regards default
contexts?
If I place data in /home/pgsql and bind-mount /var/lib/pgsql, then what
is the default context for pgsql? It depends on where restorecon was
run. If "restorecon -R /home" then pgsql will be set to the wrong
context; if "restorecon -R /var/lib" then it will be correct. And if,
for some reason, the entire filesystem gets relabelled, how do I know
which one it will get? I don't see what bind-mounting gains me anything
over my current predicament.
You are right (and it illustrates an issue with path-based security). If
the system was relabelled, it'd be pot luck whether the /home/pgsql or
/var/lib/pgsql contexts were applied. The advantages of doing the bind
mount are:
1. No tweaks to policy are needed because everything is where it's
expected to be.
2. In the event of having to relabel the system and the contexts getting
screwed up, all of the different contexts can be restored in one go with
the single command "restorecon -Rv /var/lib/pgsql", as opposed to having
to do different chcon commands for each different context that's needed.
Would --move do what is needed? The space on /home would be used for the
dir /var/lib/pgsql, which would only be there, and not both places as with
--bind.
That would be ideal but I've never got "mount --move" to work. Every
time I've tried it I get:
# mount --move /home/pgsql /var/lib/pgsql
mount: wrong fs type, bad option, bad superblock on /home/pgsql,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Perhaps someone can tell me what I'm doing wrong?
Paul.
