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: Re: NFS context mount failures
Date: Mon, 6 May 2024 12:20:46 -0400 [thread overview]
Message-ID: <CAEjxPJ6+J+c5tjVjzV4p16NzKEnSwt3J11pyeTjhVvi8whVhDw@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ67XPMa2DhZ-O1EJG+Q2ZUrjSspUf=rY1DahymiEvew3w@mail.gmail.com>
On Mon, May 6, 2024 at 10:29 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> 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...
Ok, if I undo the one part of commit cec5fe700799b ("selinux: make
labeled NFS work when mounted before policy load") that changed
inode_doinit_with_dentry() to fall through to the USE_XATTR case from
USE_NATIVE, then we no longer get the messages from
inode_doinit_use_xattr() but still fail the permission check on the
unlabeled directory and thus fail the mount operation.
prev parent reply other threads:[~2024-05-06 16:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 14:29 NFS context mount failures Stephen Smalley
2024-05-06 16:20 ` Stephen Smalley [this message]
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=CAEjxPJ6+J+c5tjVjzV4p16NzKEnSwt3J11pyeTjhVvi8whVhDw@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).