/var/spool mount denied

[QingLong-2]

        Hi, All!

   I've come across problem with mount on Fedora 9
 --- various filesystems are mounted read-only, others fails to mount at all
 due to avc denials during the system startup, e.g.:
|
| type=1400 audit(1222921979.843:4): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/lock" dev=md13 ino=62993 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
| type=1400 audit(1222921979.843:5): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/lock" dev=md13 ino=62993 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
[...]
| type=1400 audit(1222921980.322:8): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/spool" dev=md13 ino=125985 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir
| type=1400 audit(1222921980.322:9): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/spool" dev=md13 ino=125985 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir
[...]
| type=1400 audit(1222921980.331:10): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/run" dev=md13 ino=136145 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir
| type=1400 audit(1222921980.331:11): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/run" dev=md13 ino=136145 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir
|
 But after the system startup finishes (many subsystems fail to put locks, etc)
 manual `mount -a' does magically fix the situation and those filesystems
 are remounted read-writeable.

   I guess, the bug has been introduced in Fedora 9 release and is still there.
 It looks like boot time selinux policies aren't generated depending on fstab
 thus handling mount point directories and mounted filesystems incorrectly.
 Maybe I am mistaken, and the problem is caused by some more obscure reasons.

   Of course, there are chances I am just not aware of some selinux feature
 or some boolean that should be enabled to get such cases handled right.
 If so, please correct me and let me know how should I configure selinux
 to get rid of the problem. Thank you.

   This behaviour has been displayed by freshly installed Fedora 9,
 and after `yum update' it continues malfunctioning.

   My regards.
      QingLong

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Paul Howarth]

On Sat, 4 Oct 2008 21:56:55 +0400
QingLong <qinglong@...> wrote:

> Hi, All!
>
>    I've come across problem with mount on Fedora 9
>  --- various filesystems are mounted read-only, others fails to mount
> at all due to avc denials during the system startup, e.g.:
> |
> | type=1400 audit(1222921979.843:4): avc:  denied  { mounton } for
> pid=1887 comm="mount" path="/var/lock" dev=md13 ino=62993
> scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:var_lock_t:s0 tclass=dir | type=1400
> audit(1222921979.843:5): avc:  denied  { mounton } for  pid=1887
> comm="mount" path="/var/lock" dev=md13 ino=62993
> scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:var_lock_t:s0 tclass=dir [...] | type=1400
> audit(1222921980.322:8): avc:  denied  { mounton } for  pid=1887
> comm="mount" path="/var/spool" dev=md13 ino=125985
> scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:var_spool_t:s0 tclass=dir | type=1400
> audit(1222921980.322:9): avc:  denied  { mounton } for  pid=1887
> comm="mount" path="/var/spool" dev=md13 ino=125985
> scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:var_spool_t:s0 tclass=dir [...] |
> type=1400 audit(1222921980.331:10): avc:  denied  { mounton } for
> pid=1887 comm="mount" path="/var/run" dev=md13 ino=136145
> scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:var_run_t:s0 tclass=dir | type=1400
> audit(1222921980.331:11): avc:  denied  { mounton } for  pid=1887
> comm="mount" path="/var/run" dev=md13 ino=136145
> scontext=system_u:system_r:mount_t:s0
> tcontext=system_u:object_r:var_run_t:s0 tclass=dir | But after the
> system startup finishes (many subsystems fail to put locks, etc)
> manual `mount -a' does magically fix the situation and those
> filesystems are remounted read-writeable.
>
>    I guess, the bug has been introduced in Fedora 9 release and is
> still there. It looks like boot time selinux policies aren't
> generated depending on fstab thus handling mount point directories
> and mounted filesystems incorrectly. Maybe I am mistaken, and the
> problem is caused by some more obscure reasons.
>
>    Of course, there are chances I am just not aware of some selinux
> feature or some boolean that should be enabled to get such cases
> handled right. If so, please correct me and let me know how should I
> configure selinux to get rid of the problem. Thank you.
>
>    This behaviour has been displayed by freshly installed Fedora 9,
>  and after `yum update' it continues malfunctioning.

You have a somewhat unusual set of point points there.

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

It's important that the filesystems are not mounted on these
directories when you do this.

A "service netfs start" will then re-mount the directories in the same
way that it would during the boot process (or you could reboot again).
The problem should now have gone away.

Paul.

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[QingLong-2]

>
> 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.

>
> 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?

   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?

      QingLong.

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[QingLong-2]

>
> 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
>
   Just for curiousity I had changed context of /var/spool and /var/lock
 but not that of /var/run. Guess what? On the next reboot ALL of those three
 have been mounted successfully and there have been no complains or denials
 on /var/run mounting. The problem appears to be not so simple.

      QingLong.

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Paul Howarth]

On Sat, 4 Oct 2008 22:50:10 +0400
QingLong <qinglong@...> 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.

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Daniel J Walsh]

Paul Howarth wrote:

> On Sat, 4 Oct 2008 22:50:10 +0400
> QingLong <qinglong@...> 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.
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@...
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

setsebool -P allow_mount_anyfile 1


Should allow you to mount files/directories anywhere on your system

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list