From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-kernel@vger.kernel.org, linux-audit@redhat.com,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Eric Paris <eparis@redhat.com>,
Paul Moore <paul@paul-moore.com>
Subject: Re: [RFC PATCH ghak100 V1 1/2] audit: avoid fcaps on MNT_FORCE
Date: Tue, 20 Nov 2018 12:31:30 -0500 [thread overview]
Message-ID: <17943076.6Ld0qRUFEn@x2> (raw)
In-Reply-To: <20181120154820.4s6jflcnyu4ha5qn@madcap2.tricolour.ca>
On Tuesday, November 20, 2018 10:48:20 AM EST Richard Guy Briggs wrote:
> On 2018-11-20 09:17, Miklos Szeredi wrote:
> > On Mon, Nov 19, 2018 at 11:59 PM Richard Guy Briggs <rgb@redhat.com>
wrote:
> > > The simple answer is that the audit PATH record format expects the four
> > > cap_f* fields to be there and a best effort is being attempted to fill
> > > in that information in an expected way with meaningful values. Perhaps
> > > better to accept that it is unreasonable to expect any fcaps on any
> > > umount operation and simply ignore those fields in the PATH record for
> > > umount syscall events.
> >
> > When there's a mount there are in fact two objects belonging to the
> > exact same path, each having completely independent metadata: the
> > mount point and the root of the mount. For example:
> >
> > stat /mnt
> > umount /mnt
> > stat /mnt
> >
> > The first stat will show the root of the mount, the second one will
> > show the mount point.
> > Which one is the relevant for audit?
>
> It would be the root of the mount, the one that is visible to processes
> in that mount namespace.
>
> Obviously, once that mount has been unmounted, it would be the mount
> point (no longer in use as such at that point) that is of interest.
>
> On mounting, I'm guessing both would be of interest if the fcaps changed
> for that process-visible path in that mount namespace, so this provides
> an additional operation that would need recording aside from the case
> of a simple attribute change.
fcaps are on files. Mountpoints are directories. Would fcaps changes be
possible?
-Steve
> > Not saying audit should be doing getxattr on any of them, just trying
> > to see more clearly.
> >
> > Thanks,
> > Miklos
>
> - 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
next prev parent reply other threads:[~2018-11-20 17:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 17:33 [RFC PATCH ghak100 V1 0/2] audit: avoid umount hangs on missing mount Richard Guy Briggs
2018-11-16 17:33 ` [RFC PATCH ghak100 V1 1/2] audit: avoid fcaps on MNT_FORCE Richard Guy Briggs
2018-11-19 12:47 ` Miklos Szeredi
2018-11-19 22:58 ` Richard Guy Briggs
2018-11-19 22:58 ` Richard Guy Briggs
2018-11-20 8:17 ` Miklos Szeredi
2018-11-20 15:48 ` Richard Guy Briggs
2018-11-20 17:31 ` Steve Grubb [this message]
2018-11-16 17:33 ` [RFC PATCH ghak100 V1 2/2] audit: moar filter PATH records keyed on filesystem magic Richard Guy Briggs
2018-12-12 13:03 ` [RFC PATCH ghak100 V1 0/2] audit: avoid umount hangs on missing mount Paul Moore
2018-12-14 16:27 ` Richard Guy Briggs
2018-12-14 22:02 ` Paul Moore
2018-12-14 23:03 ` Richard Guy Briggs
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=17943076.6Ld0qRUFEn@x2 \
--to=sgrubb@redhat.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paul@paul-moore.com \
--cc=rgb@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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.