linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Jann Horn <jannh@google.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2
Date: Sun, 30 Aug 2020 21:46:33 -0400	[thread overview]
Message-ID: <20200831014633.GJ3265@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAG48ez2tOBAKLaX-siRZPCLiiy-s65w2mFGDGr4q2S7WFxpK1A@mail.gmail.com>

On Mon, Aug 31, 2020 at 03:15:04AM +0200, Jann Horn wrote:
> On Sun, Aug 30, 2020 at 10:00 PM Rich Felker <dalias@libc.org> wrote:
> > On Sun, Aug 30, 2020 at 09:02:31PM +0200, Jann Horn wrote:
> > > On Sun, Aug 30, 2020 at 8:43 PM Rich Felker <dalias@libc.org> wrote:
> > > > On Sun, Aug 30, 2020 at 08:31:36PM +0200, Jann Horn wrote:
> > > > > On Sun, Aug 30, 2020 at 6:36 PM Rich Felker <dalias@libc.org> wrote:
> > > > > > So just checking IS_APPEND in the code paths used by
> > > > > > pwritev2 (and erroring out rather than silently writing output at the
> > > > > > wrong place) should suffice to preserve all existing security
> > > > > > invariants.
> > > > >
> > > > > Makes sense.
> > > >
> > > > There are 3 places where kiocb_set_rw_flags is called with flags that
> > > > seem to be controlled by userspace: aio.c, io_uring.c, and
> > > > read_write.c. Presumably each needs to EPERM out on RWF_NOAPPEND if
> > > > the underlying inode is S_APPEND. To avoid repeating the same logic in
> > > > an error-prone way, should kiocb_set_rw_flags's signature be updated
> > > > to take the filp so that it can obtain the inode and check IS_APPEND
> > > > before accepting RWF_NOAPPEND? It's inline so this should avoid
> > > > actually loading anything except in the codepath where
> > > > flags&RWF_NOAPPEND is nonzero.
> > >
> > > You can get the file pointer from ki->ki_filp. See the RWF_NOWAIT
> > > branch of kiocb_set_rw_flags().
> >
> > Thanks. I should have looked for that. OK, so a fixup like this on top
> > of the existing patch?
> >
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 473289bff4c6..674131e8d139 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -3457,8 +3457,11 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags)
> >                 ki->ki_flags |= (IOCB_DSYNC | IOCB_SYNC);
> >         if (flags & RWF_APPEND)
> >                 ki->ki_flags |= IOCB_APPEND;
> > -       if (flags & RWF_NOAPPEND)
> > +       if (flags & RWF_NOAPPEND) {
> > +               if (IS_APPEND(file_inode(ki->ki_filp)))
> > +                       return -EPERM;
> >                 ki->ki_flags &= ~IOCB_APPEND;
> > +       }
> >         return 0;
> >  }
> >
> > If this is good I'll submit a v2 as the above squashed with the
> > original patch.
> 
> Looks good to me.

Actually it's not quite. I think it should be:

	if ((flags & RWF_NOAPPEND) & (ki->ki_flags & IOCB_APPEND)) {
		if (IS_APPEND(file_inode(ki->ki_filp)))
			return -EPERM;
		ki->ki_flags &= ~IOCB_APPEND;
	}

i.e. don't refuse RWF_NOAPPEND on a file that was already successfully
opened without O_APPEND that only subsequently got chattr +a. The
permission check should only be done if it's overriding the default
action for how the file is open.

This is actually related to the fcntl corner case mentioned before.

Are you ok with this change? If so I'll go ahead and prepare a v2.

Rich

  reply	other threads:[~2020-08-31  1:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29  2:00 [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2 Rich Felker
2020-08-30 15:05 ` Jann Horn
2020-08-30 16:36   ` Rich Felker
2020-08-30 18:31     ` Jann Horn
2020-08-30 18:43       ` Rich Felker
2020-08-30 19:02         ` Jann Horn
2020-08-30 20:00           ` Rich Felker
2020-08-31  1:15             ` Jann Horn
2020-08-31  1:46               ` Rich Felker [this message]
2020-08-31  9:15                 ` Jann Horn
2020-08-31 12:57                   ` Rich Felker
2020-08-31 13:12                     ` Jann Horn

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=20200831014633.GJ3265@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=jannh@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).