SELinuxProject / selinux-testsuite

This is the upstream SELinux testsuite which is designed as a basic set of regression tests for the SELinux kernel functionality.
GNU General Public License v2.0
54 stars 43 forks source link

BUG: overlay tests not cleaning up successfully #72

Closed stephensmalley closed 4 years ago

stephensmalley commented 4 years ago

I think this has been an issue for a while and perhaps forever but wanted to note it. It appears that the overlay tests are not successfully cleaning up. During make test, we get the following error output even though the tests themselves pass:

overlay/test ................ 119/119 rm: cannot remove 'overlay/container1/merged/noaccessfile': Permission denied rm: cannot remove 'overlay/container1/merged/noaccessdir': Is a directory

Afterward, the overlay mount is still present: $ mount | grep overlay none on /home/sds/selinux-testsuite/tests/overlay/container1/merged type overlay (rw,relatime,context=system_u:object_r:unlabeled_t:s0,lowerdir=overlay/lower,upperdir=overlay/container1/upper,workdir=overlay/container1/work)

This can then break subsequent attempts to run the testsuite without manually unmounting or rebooting.

pcmoore commented 4 years ago

I'm not seeing this failure ... ? The output below is taken from today's test run:

Compiling targeted test_policy module
Creating targeted test_policy.pp policy package
Running as user root with context unconfined_u:unconfined_r:unconfined_t

domain_trans/test ........... ok
entrypoint/test ............. ok
execshare/test .............. ok
exectrace/test .............. ok
execute_no_trans/test ....... ok
fdreceive/test .............. ok
inherit/test ................ ok
link/test ................... ok
mkdir/test .................. ok
msg/test .................... ok
open/test ................... ok
ptrace/test ................. ok
readlink/test ............... ok
relabel/test ................ ok
rename/test ................. ok
rxdir/test .................. ok
sem/test .................... ok
setattr/test ................ ok
setnice/test ................ ok
shm/test .................... ok
sigkill/test ................ ok
stat/test ................... ok
sysctl/test ................. ok
task_create/test ............ ok
task_setnice/test ........... ok
task_setscheduler/test ...... ok
task_getscheduler/test ...... ok
task_getsid/test ............ ok
task_getpgid/test ........... ok
task_setpgid/test ........... ok
file/test ................... ok
ioctl/test .................. ok
capable_file/test ........... ok
capable_net/test ............ ok
capable_sys/test ............ ok
dyntrans/test ............... ok
dyntrace/test ............... ok
bounds/test ................. ok
nnp_nosuid/test ............. ok
mmap/test ................... ok
unix_socket/test ............ ok
inet_socket/test ............ ok
overlay/test ................ ok
checkreqprot/test ........... ok
mqueue/test ................. ok
mac_admin/test .............. ok
atsecure/test ............... ok
cap_userns/test ............. ok
extended_socket_class/test .. ok
sctp/test ................... ok
netlink_socket/test ......... ok
prlimit/test ................ ok
binder/test ................. ok
bpf/test .................... ok
keys/test ................... ok
infiniband_endport/test ..... ok
infiniband_pkey/test ........ ok
cgroupfs_label/test ......... ok
All tests successful.
Files=58, Tests=662, 119 wallclock secs ( 0.23 usr  0.21 sys +  5.92 cusr 21.70 csys = 28.06 CPU)
Result: PASS
libsemanage.semanage_direct_remove_key: Removing last test_policy module (no other test_policy module exists at another priority).
WOnder93 commented 4 years ago

I'm not seeing this error either... is there something specific about your setup?

stephensmalley commented 4 years ago

Having trouble reproducing now, but it definitely happened and I remember seeing it a number of times before. Possible factors: kernel debugging options enabled, may have been with a patch on top of selinux/next or on top of selinux-testsuite that I was testing at the time, might have run make test previously without cleaning in between, might have had a failed prior make test run. Anyway, I guess I'll wait until I see it again and try to capture all the details.

stephensmalley commented 4 years ago

Closing this issue for now since it seems difficult to reproduce; will re-open or create a new one if it recurs,