stuck on ghak100 testsuite script

[Ondrej Mosnacek]

On Mon, Nov 12, 2018 at 2:32 PM Richard Guy Briggs <rgb at redhat.com> wrote:
> On 2018-11-12 12:32, Ondrej Mosnacek wrote:
> > On Sun, Nov 11, 2018 at 11:36 PM Richard Guy Briggs <rgb at redhat.com> wrote:
> > > On 2018-11-11 17:24, Ondrej Mosnacek wrote:
> > > > Hi Richard,
> > > > On Fri, Nov 9, 2018 at 11:04 PM Richard Guy Briggs <rgb at redhat.com> wrote:
> > > > > Hi Paul, Ondrej,
> > > > >
> > > > > I've got a couple of patches with two different approaches to address
> > > > > ghak100:
> > > > >         https://github.com/linux-audit/audit-kernel/issues/100
> > > > >
> > > > > The patches work, but I've not posted them yet because I wanted to
> > > > > update the audit-testsuite first to consistently test it.
> > > > >
> > > > > I've written a test to automate the regression test to add to
> > > > > audit-testsuite based on the reproducer recipe provided in ghak100.  The
> > > > > procedure in the description of ghak100 works, but I'm having some
> > > > > trouble with the script.  In particular, it is hanging the script on the
> > > > > "kill 'SIGSTOP' $pid_fuse" line.  Once it hangs, the main script, the
> > > > > test subscript and both backgrounded processes (fuse and umount) are
> > > > > still hanging around.
> > > > >
> > > > > Here's the script:
> > > > >         https://github.com/linux-audit/audit-testsuite/compare/master...rgbriggs:ghak100-missing-mount-hang
> > > > >
> > > > > Do either of you have any insight why this might be happenning and how
> > > > > to fix or work around it?
> > > > >
> > > > > A couple of minor notes:
> > > > > - The $pid_fuse += 1 is necessary since it forks from the PID reported
> > > > >   to the shell.
> > > >
> > > > I don't understand... why do you expect the forked PID to be exactly
> > > > one higher? This doesn't seem to be the case in general:
> > > >
> > > > $ (echo $$; exec bash -c 'echo $$' &)
> > > > 10995
> > > > 13693
> > >
> > > I was not happy with this hack, but this was the most expedient way to
> > > try to get a first attempt working...  I suppose a better way might be
> > > to spawn the client which forks, then use something like pgrep to find
> > > all the instances and eliminate the PID that was returned by the launch.
> >
> > How about something like:
> >
> >   system("cd $basedir/$clientdir; mkfifo /tmp/fifo; sh -c 'echo $$ >
> > /tmp/fifo; exec ./$client -f -s $tmpdir' & cat /tmp/fifo");
> >
> > That should always give you the right PID. You just need to tweak it
> > to create the FIFO as a temporary file and clean it up afterwards. It
> > is more complicated, but should be reliable.
>
> I don't understand why all this extra?  It will still list the first
> PID of the newly forked task.  There are several examples of
> capturing the PID of a backgrounded process already in the
> audit-testsuite which all work fine:
>         tests/filter_sessionid/test (touch)
>         tests/login_tty/test (echo)
>         tests/lost_reset/test (auditctl --reset-lost)
>         tests/user_msg/test (auditctl -m ...)
>
> The problem here is that the client that is executed then forks, which
> isn't the case with any of the examples listed above.

Do you mean that the client itself forks, too? I thought you are only
trying to deal with the fork done by the shell via the '&' operator.
My solution of course handles only that (by forking a shell, reporting
its PID into a fifo and then exec'ing the fuse client). But shouldn't
the '-f' and '-s' option of fusexmp prevent it from forking on its
own?

>
> > > As far as I can tell, I was hitting the right task since hitting the
> > > wrong or non-existant task didn't hang the test.
> >
> > Yes, when I fork from a fresh shell, I also get the forked PID one
> > greater practically every time, so that will be a different problem...
> > I didn't look at the hang problem yet, I will try it later in the
> > afternoon.
> >
> > > > > - The SIGSTOP is necessary to simulate the hung filesystem.
> > > > >
> > > > > - RGB
> > > >
> > > > Ondrej Mosnacek <omosnace at redhat dot com>
> > >
> > > - RGB
> >
> > Ondrej Mosnacek <omosnace at redhat dot com>
>
> - RGB
>
> --
> Richard Guy Briggs <rgb at redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635

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