/var/spool mount denied

[Paul Howarth]

On Sat, 4 Oct 2008 22:50:10 +0400
QingLong <qinglong at 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 are left
> > 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
> >
>    Thank you.
> 
>    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 several others)
>  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.

Paul.