On Fri, 2020-03-13 at 14:22 -0400, Stephen Smalley wrote: > 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:s > > > 0- > > > 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. Could you try adding "userdom_search_user_home_content(filesystemdomain)" to test_filesystem.te as I had that in RFC V3 patch but removed it when I ran restorecon my system.
