On Fri, Mar 13, 2020 at 2:18 PM Richard Haines <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > On Fri, 2020-03-13 at 13:21 -0400, Stephen Smalley wrote: > > On Fri, Mar 13, 2020 at 12:04 PM Stephen Smalley > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > On Fri, Mar 13, 2020 at 11:47 AM Stephen Smalley > > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Thu, Mar 12, 2020 at 7:37 AM Richard Haines > > > > <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > > > > If you test on the selinux-next kernel (that has the XFS patch > > > > > [1]) with > > > > > the "NFS: Ensure security label is set for root inode" patch > > > > > [2], then all > > > > > tests should pass. Anything else will give varying amounts of > > > > > fails. > > > > > > > > > > The filesystem types tested are: ext4, xfs, vfat and nfs4. > > > > > > > > > > I've revamped the nfs.sh to handle tests that require specific > > > > > mount > > > > > options, these plus many more are now in tests/nfs_filesystem. > > > > > This only > > > > > gets run by nfs.sh. > > > > > > > > > > There are two minor workarounds involving multiple mounts > > > > > returning EBUSY. > > > > > These are either bugs or features. > > > > > > > > > > [1] > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/patch/security/selinux?id=e4cfa05e9bfe286457082477b32ecd17737bdbce > > > > > [2] > > > > > https://lore.kernel.org/selinux/20200303225837.1557210-1-smayhew@xxxxxxxxxx/ > > > > > > > > Still failing for me: > > > > filesystem/test ............. 13/27 Failed mount(2): Permission > > > > denied > > > > filesystem/test ............. 18/27 > > > > > > Sorry, that's on me. Wrong kernel. Will retry... > > > > Same failures with the right kernel. If I am reading it correctly, > > the first failure is on this test: > > > > 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 ); > > > > Looks like the denial was: > > type=SYSCALL msg=audit(03/13/2020 13:11:37.805:1605) : arch=x86_64 > > syscall=mount success=no exit=EACCES(Permission denied) > > a0=0x7ffc28975328 a1=0x7ffc2897536b a2=0x7ffc28975386 a3=0x0 items=14 > > ppid=15745 pid=15886 auid=sds uid=root gid=root euid=root suid=root > > fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=mount > > exe=/mnt/selinux-testsuite/tests/filesystem/mount > > subj=unconfined_u:unconfined_r:test_filesystem_no_getattr_t:s0- > > s0:c0.c1023 > > key=(null) > > type=AVC msg=audit(03/13/2020 13:11:37.805:1605) : avc: denied { > > search } for pid=15886 comm=mount name=sds dev="0:49" ino=17039361 > > scontext=unconfined_u:unconfined_r:test_filesystem_no_getattr_t:s0- > > s0:c0.c1023 > > tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir > > permissive=0 > > So far I have not managed to see this problem before or after a > restorecon. I'll investigate further and see what I can find !!! I was wondering if it has to do with where the testsuite directory is located. In my case, under my $HOME. Most of the test domains don't need access to the parent directories of the test subdir because they only use relative pathnames but a few do require this.
