From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Ondrej Mosnacek <omosnace@redhat.com>,
Paul Moore <paul@paul-moore.com>,
SElinux list <selinux@vger.kernel.org>
Subject: NFS context mount failures
Date: Mon, 6 May 2024 10:29:36 -0400 [thread overview]
Message-ID: <CAEjxPJ67XPMa2DhZ-O1EJG+Q2ZUrjSspUf=rY1DahymiEvew3w@mail.gmail.com> (raw)
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...
next reply other threads:[~2024-05-06 14:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 14:29 Stephen Smalley [this message]
2024-05-06 16:20 ` NFS context mount failures Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEjxPJ67XPMa2DhZ-O1EJG+Q2ZUrjSspUf=rY1DahymiEvew3w@mail.gmail.com' \
--to=stephen.smalley.work@gmail.com \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).