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;
MIME-Version: 1.0
References: <cover.1542149969.git.rgb@redhat.com> <218e806e61cd5ae2fd38f9d546f953f86c763b58.1542149969.git.rgb@redhat.com>
 <CAJfpegtA74ULckL+PXoM9_pynV78EKOpQ603iZrp=hfR0z0z7w@mail.gmail.com> <20181119225856.dt3l7qzg2ftggon4@madcap2.tricolour.ca>
In-Reply-To: <20181119225856.dt3l7qzg2ftggon4@madcap2.tricolour.ca>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Tue, 20 Nov 2018 09:17:15 +0100
Message-ID: <CAJfpegt8H-8-PJyJbGe9zQB1DxBQLoMA0QRhc-gAH=mw6YKhVw@mail.gmail.com>
Subject: Re: [RFC PATCH ghak100 V1 1/2] audit: avoid fcaps on MNT_FORCE
To:     Richard Guy Briggs <rgb@redhat.com>
Cc:     linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
        linux-kernel@vger.kernel.org, linux-audit@redhat.com,
        Paul Moore <paul@paul-moore.com>,
        Eric Paris <eparis@redhat.com>, sgrubb@redhat.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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?

Not saying audit should be doing getxattr on any of them, just trying
to see more clearly.

Thanks,
Miklos