Message ID | 20200109150709.360345-1-richard_c_haines@btinternet.com (mailing list archive) |
---|---|
Headers | show |
Series | selinux-testsuite: Add filesystem tests | expand |
On 1/9/20 10:07 AM, Richard Haines wrote: > These tests should cover all the areas in selinux/hooks.c that touch > the 'filesystem' class. Each hooks.c function is listed in the 'test' > script as there are some permissions that are checked in multiple places. > > Tested on Fedora 31 and Rawhide (5.5 for the new watch perm). > > V2 Changes: > 1) If udisks(8) daemon is running, stop then restart after tests. The tests > run faster and stops the annoying habit of adding mounts to the 'files' > app on the desktop. Supports /usr/bin/systemctl or /usr/sbin/service > More importantly it stops interferance with the '*context=' tests as it > can cause intermittent failures. Tested by running 'test' in a continuous > loop with udisks enabled, and then again disabled. > Loop 200 times, with udisks failed between 1 to 70 iterations, without > udisks, no failures. Wondering why udisks is causing failures - that seems like another bug.
On Thu, 2020-01-09 at 13:04 -0500, Stephen Smalley wrote: > On 1/9/20 10:07 AM, Richard Haines wrote: > > These tests should cover all the areas in selinux/hooks.c that > > touch > > the 'filesystem' class. Each hooks.c function is listed in the > > 'test' > > script as there are some permissions that are checked in multiple > > places. > > > > Tested on Fedora 31 and Rawhide (5.5 for the new watch perm). > > > > V2 Changes: > > 1) If udisks(8) daemon is running, stop then restart after tests. > > The tests > > run faster and stops the annoying habit of adding mounts to the > > 'files' > > app on the desktop. Supports /usr/bin/systemctl or > > /usr/sbin/service > > More importantly it stops interferance with the '*context=' > > tests as it > > can cause intermittent failures. Tested by running 'test' in a > > continuous > > loop with udisks enabled, and then again disabled. > > Loop 200 times, with udisks failed between 1 to 70 iterations, > > without > > udisks, no failures. > > Wondering why udisks is causing failures - that seems like another > bug. With udisk2 enabled, 99% of the time the 'rootcontext=' test fails (the 1% is 'defcontext='). However if I run this test on its own, it does not fail. If I add the 'context=' test before and run, the 'rootcontext=' will fail at some point. If I add a short delay as shown in the 'context=' sequence, the fault does not occur: -- Start -- system("losetup -d $dev 2>/dev/null"); system("sleep 0.01"); get_loop_dev(); attach_dev(); # Mount again with no xttr support $context2_opts = "context=system_u:object_r:test_filesystem_context_t:s0"; -- End -- It could be udisk2 has a timing problem as the losetup(8) man page '-d' entry reads: Note that since Linux v3.7 kernel uses "lazy device destruction". The detach operation does not return EBUSY error anymore if device is actively used by system, but it is marked by autoclear flag and destroyed later. But then again it could be something else !!!!
On Thu, Jan 9, 2020 at 9:36 PM Richard Haines <richard_c_haines@btinternet.com> wrote: > On Thu, 2020-01-09 at 13:04 -0500, Stephen Smalley wrote: > > On 1/9/20 10:07 AM, Richard Haines wrote: > > > These tests should cover all the areas in selinux/hooks.c that > > > touch > > > the 'filesystem' class. Each hooks.c function is listed in the > > > 'test' > > > script as there are some permissions that are checked in multiple > > > places. > > > > > > Tested on Fedora 31 and Rawhide (5.5 for the new watch perm). > > > > > > V2 Changes: > > > 1) If udisks(8) daemon is running, stop then restart after tests. > > > The tests > > > run faster and stops the annoying habit of adding mounts to the > > > 'files' > > > app on the desktop. Supports /usr/bin/systemctl or > > > /usr/sbin/service > > > More importantly it stops interferance with the '*context=' > > > tests as it > > > can cause intermittent failures. Tested by running 'test' in a > > > continuous > > > loop with udisks enabled, and then again disabled. > > > Loop 200 times, with udisks failed between 1 to 70 iterations, > > > without > > > udisks, no failures. > > > > Wondering why udisks is causing failures - that seems like another > > bug. > > With udisk2 enabled, 99% of the time the 'rootcontext=' test fails (the > 1% is 'defcontext='). However if I run this test on its own, it does > not fail. If I add the 'context=' test before and run, the > 'rootcontext=' will fail at some point. > > If I add a short delay as shown in the 'context=' sequence, the fault > does not occur: > -- Start -- > system("losetup -d $dev 2>/dev/null"); > system("sleep 0.01"); > get_loop_dev(); > attach_dev(); Can you try putting `udevadm settle` instead of the sleep there? I remember having some issues with udev race conditions a long time ago and I think that helped. (But I'm not sure at all if that's the right fix...) > > # Mount again with no xttr support > $context2_opts = > "context=system_u:object_r:test_filesystem_context_t:s0"; > -- End -- > > It could be udisk2 has a timing problem as the losetup(8) man page '-d' > entry reads: > Note that since Linux v3.7 kernel uses "lazy device destruction". The > detach operation does not return EBUSY error anymore if device is > actively used by system, but it is marked by autoclear flag and > destroyed later. > > But then again it could be something else !!!! > >
On Thu, 2020-01-09 at 22:01 +0100, Ondrej Mosnacek wrote: > On Thu, Jan 9, 2020 at 9:36 PM Richard Haines > <richard_c_haines@btinternet.com> wrote: > > On Thu, 2020-01-09 at 13:04 -0500, Stephen Smalley wrote: > > > On 1/9/20 10:07 AM, Richard Haines wrote: > > > > These tests should cover all the areas in selinux/hooks.c that > > > > touch > > > > the 'filesystem' class. Each hooks.c function is listed in the > > > > 'test' > > > > script as there are some permissions that are checked in > > > > multiple > > > > places. > > > > > > > > Tested on Fedora 31 and Rawhide (5.5 for the new watch perm). > > > > > > > > V2 Changes: > > > > 1) If udisks(8) daemon is running, stop then restart after > > > > tests. > > > > The tests > > > > run faster and stops the annoying habit of adding mounts to > > > > the > > > > 'files' > > > > app on the desktop. Supports /usr/bin/systemctl or > > > > /usr/sbin/service > > > > More importantly it stops interferance with the '*context=' > > > > tests as it > > > > can cause intermittent failures. Tested by running 'test' > > > > in a > > > > continuous > > > > loop with udisks enabled, and then again disabled. > > > > Loop 200 times, with udisks failed between 1 to 70 > > > > iterations, > > > > without > > > > udisks, no failures. > > > > > > Wondering why udisks is causing failures - that seems like > > > another > > > bug. > > > > With udisk2 enabled, 99% of the time the 'rootcontext=' test fails > > (the > > 1% is 'defcontext='). However if I run this test on its own, it > > does > > not fail. If I add the 'context=' test before and run, the > > 'rootcontext=' will fail at some point. > > > > If I add a short delay as shown in the 'context=' sequence, the > > fault > > does not occur: > > -- Start -- > > system("losetup -d $dev 2>/dev/null"); > > system("sleep 0.01"); > > get_loop_dev(); > > attach_dev(); > > Can you try putting `udevadm settle` instead of the sleep there? I > remember having some issues with udev race conditions a long time ago > and I think that helped. (But I'm not sure at all if that's the right > fix...) Thanks - I had to add this to a couple of places and worked okay for 200 interations on Rawhide. On the next patch version would you like the udisks2_stop()/udisks2_restart() functions removed, left as is or set as an option for the test when run locally ?? > > > # Mount again with no xttr support > > $context2_opts = > > "context=system_u:object_r:test_filesystem_context_t:s0"; > > -- End -- > > > > It could be udisk2 has a timing problem as the losetup(8) man page > > '-d' > > entry reads: > > Note that since Linux v3.7 kernel uses "lazy device destruction". > > The > > detach operation does not return EBUSY error anymore if device is > > actively used by system, but it is marked by autoclear flag and > > destroyed later. > > > > But then again it could be something else !!!! > > > >