On Thu, Jan 9, 2020 at 9:36 PM Richard Haines
<richard_c_haines@xxxxxxxxxxxxxx> 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 !!!!
>
>
--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
