All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Mosnacek <omosnace@redhat.com>
To: Richard Haines <richard_c_haines@btinternet.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH V2 0/1] selinux-testsuite: Add filesystem tests
Date: Thu, 9 Jan 2020 22:01:47 +0100	[thread overview]
Message-ID: <CAFqZXNvKgGfbcmaMExG6HK=nmeS22VCSumjAZMqSaNzxC+0Qfg@mail.gmail.com> (raw)
In-Reply-To: <4eefc9594eec6010c8427a3308e5e3c3fdabbf3b.camel@btinternet.com>

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 !!!!
>
>

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.


  reply	other threads:[~2020-01-09 21:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:07 [PATCH V2 0/1] selinux-testsuite: Add filesystem tests Richard Haines
2020-01-09 15:07 ` [PATCH V2 1/1] " Richard Haines
2020-01-09 17:14   ` Stephen Smalley
2020-01-09 17:40     ` Richard Haines
2020-01-09 17:19   ` Stephen Smalley
2020-01-09 17:45     ` Richard Haines
2020-01-10 18:09     ` Richard Haines
2020-01-10 18:18       ` Stephen Smalley
2020-01-12 16:04         ` Richard Haines
2020-01-13 13:52           ` Stephen Smalley
2020-01-13 14:07             ` Stephen Smalley
2020-01-13 18:00               ` Richard Haines
2020-01-13 18:54                 ` Stephen Smalley
2020-01-09 17:46   ` Stephen Smalley
2020-01-09 17:51     ` Richard Haines
2020-01-09 18:04 ` [PATCH V2 0/1] " Stephen Smalley
2020-01-09 20:36   ` Richard Haines
2020-01-09 21:01     ` Ondrej Mosnacek [this message]
2020-01-10 14:28       ` Richard Haines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFqZXNvKgGfbcmaMExG6HK=nmeS22VCSumjAZMqSaNzxC+0Qfg@mail.gmail.com' \
    --to=omosnace@redhat.com \
    --cc=richard_c_haines@btinternet.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.