Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 14 Dec 2018 11:27:44 -0500
From:   Richard Guy Briggs <rgb@redhat.com>
To:     Paul Moore <paul@paul-moore.com>
Cc:     linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
        linux-kernel@vger.kernel.org, linux-audit@redhat.com,
        Eric Paris <eparis@redhat.com>, sgrubb@redhat.com
Subject: Re: [RFC PATCH ghak100 V1 0/2] audit: avoid umount hangs on missing
 mount
Message-ID: <20181214162744.23sbfyl3rnwkgoie@madcap2.tricolour.ca>
References: <cover.1542149969.git.rgb@redhat.com>
 <CAHC9VhT8iFLSXJBvocg_aPeveBy0hZ4bxZ547ufbUsTnkONpZg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHC9VhT8iFLSXJBvocg_aPeveBy0hZ4bxZ547ufbUsTnkONpZg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2018-12-12 08:03, Paul Moore wrote:
> On Fri, Nov 16, 2018 at 12:34 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > On user and remote filesystems, a forced umount can still hang due to
> > attemting to fetch the fcaps of a mounted filesystem that is no longer
> > available.
> >
> > These two patches take different approaches to address this, one by
> > avoiding the lookup when the MNT_FORCE flag is included, the other by
> > providing a method to filter out auditing specified types of filesystems.
> >
> > This can happen on ceph, cifs, 9p, lustre, fuse (gluster) or NFS.
> >
> > Arguably the better way to address this issue is to disable auditing
> > processes that touch removable filesystems.
> > Please see the github issue tracker
> > https://github.com/linux-audit/audit-kernel/issues/100
> >
> > Richard Guy Briggs (2):
> >   audit: avoid fcaps on MNT_FORCE
> >   audit: moar filter PATH records keyed on filesystem magic
> >
> >  fs/namei.c            |  2 +-
> >  fs/namespace.c        |  3 +++
> >  include/linux/audit.h |  8 ++++++--
> >  kernel/audit.c        |  5 +++--
> >  kernel/audit.h        |  2 +-
> >  kernel/auditsc.c      | 29 ++++++++++++++++++++++++++---
> >  6 files changed, 40 insertions(+), 9 deletions(-)
> 
> Just to get this out of the way, don't use "moar", spell it properly.
> 
> Beyond that, it's not clear to me from your cover letter if you are
> proposing these patches as an "or" or as an "and"; assuming the
> patch(es) are reasonable, do you want us to merge both of these
> patches, or only the one we like the most?

I would like each one to be considered on its own merits.

The second was discussed back when the logs were flooded with "(null)"
PATH records due to debugfs and tracefs noise.  Do you agree with the
general concept or not?

The first is being picked apart (rightfully) due to assumptions and
choices made long ago in the audit system.  So while it is still in far
more flux than the second patch, I think it has the potential to fix the
problem more correctly and permanently but in the process may challenge
our rules about the format and invariability of audit records.  The
basic premise is to prevent audit from trying to get information (fcaps)
from a filesystem that is likely to be far more ephemeral than local
on-disk kernel filesystems or to fail to do so more gracefully.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@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