On Sat, 4 Oct 2008 22:50:10 +0400
QingLong <qinglong(a)Bolizm.ihep.su> wrote:
> You have a somewhat unusual set of point points there.
Well, I know.
But I use to use different fs types and fs parameters (and mount
options) as various filesystem parts have different functionality and
operating modes. E.g. traditional news spool on a Usenet News server
needs lo-o-ots of inodes.
/var/spool I can understand, but /var/lock and /var/run?
> Fix for now: reboot so that all "problem" filesystems
> unmounted (or manually unmount all of them), then change the context
> type of the mountpoint directories to mnt_t:
> # chcon -t mnt_t /var/run /var/spool /var/lock
And a bit more questions, if you let me.
Once the problem is in the context of mount points,
then how does post-startup manual `mount -a' succeed?
I believe it would fail quite in the same manner, wouldn't it?
No, because when you run "mount" manually like this, it runs
"unconfined" - there is no transition to the mount_t domain in SELinux,
and hence you're not affected. At boot time, mount is run from an
initscript and the transition happens, so mount is constrained about
what it can do by SELinux.
And why don't other ``unusual'' filesystems (I have
fail in the same way, but get mounted during startup quite
successfully? Aren't there some race conditions?
Many of the more commonly-used mountpoints are configured as such in
SELinux policy (/var/spool/mail for instance) and don't cause problems.