[PATCH v2] fs, security: Fix file_set_fowner LSM hook inconsistencies

[Paul Moore]

On Wed, Aug 14, 2024 at 8:35 AM Mickaël Salaün <mic at digikod.net> wrote:
> On Tue, Aug 13, 2024 at 07:39:45PM -0400, Paul Moore wrote:
> > On Tue, Aug 13, 2024 at 2:28 PM Mickaël Salaün <mic at digikod.net> wrote:
> > > On Tue, Aug 13, 2024 at 11:04:13AM -0400, Paul Moore wrote:
> > > > On Tue, Aug 13, 2024 at 6:05 AM Mickaël Salaün <mic at digikod.net> wrote:
> > > > > On Mon, Aug 12, 2024 at 06:26:58PM -0400, Paul Moore wrote:
> > > > > > On Mon, Aug 12, 2024 at 1:44 PM Mickaël Salaün <mic at digikod.net> wrote:

...

> > > > > it guarantees
> > > > > that the VFS semantic is always visible to each LSMs thanks to the use
> > > > > of the same f_owner.cred
> > > >
> > > > The existing hooks are designed to make sure that the F_SETOWN
> > > > operation is visible to the LSM.
> > >
> > > This should not change the F_SETOWN case.  Am I missing something?
> >
> > I don't know, you were talking about making sure the VFS semantics are
> > visible to the LSM and I was simply suggesting that the existing hooks
> > do that too.  To be honest, whatever point you are trying to make here
> > isn't very clear to me.
>
> The existing hooks does not reflect the VFS semantic because
> of the `if (force || !filp->f_owner.pid)` checks in f_modown().
> When f_modown() is explitly called from user space (F_SETOWN), force is
> true, but that is not the case for all call sites (e.g. TUN, TTY,
> dnotify).

Thanks for the clarification.  I believe moving the hook as discussed
should resolve this too.

-- 
paul-moore.com