NFS context mount failures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So I'm looking into the remaining failures when running the nfs.sh
tests in the selinux-testsuite, and the next failures are during
mount(2) when using the fscontext mount option, with the following
messages showing up repeatedly in dmesg output:
[  446.205230] SELinux: inode_doinit_use_xattr:  getxattr returned 95
for dev=0:59 ino=632702863
[  446.205344] SELinux: inode_doinit_use_xattr:  getxattr returned 95
for dev=0:59 ino=632702863
[  446.205383] SELinux: inode_doinit_use_xattr:  getxattr returned 95
for dev=0:59 ino=632702863
[  446.205387] SELinux: inode_doinit_use_xattr:  getxattr returned 95
for dev=0:59 ino=632702863

The errno 95 corresponds to EOPNOTSUPP. __vfs_getxattr() returns this
when there is no handler for the attribute name. The NFS handler for
getting security.* is nfs4_xattr_get_nfs4_label(), which calls
security_ismaclabel() to check whether the name is in fact the
attribute name that corresponds to the MAC label, and SELinux returns
1 for its name so I am unclear as to why we are getting this error.

Line 709 of tests/filesystem/test is the first such failure:
print "Mount $fs_type filesystem on $basedir/mntpoint/mp1\n";
print "Using mount options:\n\t$mount_opts\n";
$result = system(
"runcon -t test_filesystem_no_getattr_t $basedir/mount -s $dev -t
$basedir/mntpoint/mp1 -f $fs_type -o $mount_opts -v"
);
ok( $result eq 0 );

Verbose output is:
Run 'filesystem' tests with mount context option:
fscontext=system_u:object_r:test_filesystem_file_t:s0
filesystem/test .. 1/41 Failed mount(2): Permission denied

AVC message is:
type=AVC msg=audit(05/06/2024 10:14:42.359:3649) : avc:  denied  {
search } for  pid=11312 comm=mount name=mntpoint dev="0:54"
ino=285625107 scontext=unconfined_u:unconfined_r:test_filesystem_no_getattr_t:s0-s0:c0.c1023
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

Unsurprising that it is unlabeled_t since the getxattr failed, so the
getxattr failure seems to be the key here.

Maybe because this is happening during mount(2), the server isn't yet
offering labels and that's the cause? I know we had a similar problem
with FUSE filesystems when we were trying to allow labeling of
those...




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux