Hello,
I have a question regarding the mount_t context on RHEL5 (but for my
purposes the recent Fedora SELinux policies are equally relevant).
I am having a problem where occasionally the 'umount' binary hangs because
the filesystem being unmounted (OpenAFS) tries to do network I/O as part
of the kernel code path triggered by the umount() system call.
The actual audit messages in the log look like this:
audit(1199237877.841:1837): avc: denied { write } for pid=29174 comm="umount" lport=7001 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=udp_socket
What's happening here, as far as I can tell, is that the openafs
filesystem (kernel code) tries to do some network I/O from inside the
umount() system call. Because this happens in the context of the umount
process itself, SELinux applies the same restrictions that it would have
if umount had deliberately used sockets itself.
(The UDP socket in question, bound to port 7001, would have been created
at the time that the openafs filesystem was initialized)
My question is:
What does the current SELinux policy (e.g. targeted policy) on Fedora do
for the case of NFS and cifs, for the mount_t context? Can mount/umount
perform any network I/O, or is this restricted?
Thanks,
Chris Wing
wingc@xxxxxxxxx
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
