On Mon, 2020-09-21 at 17:30 +0100, Al Viro wrote:
> On Mon, Sep 21, 2020 at 06:09:22PM +0200, Christoph Hellwig wrote:
> > [adding Linus and Al]
> >
> > On Mon, Sep 21, 2020 at 04:51:35PM +0200, Ondrej Mosnacek wrote:
> > > Hi folks,
> > >
> > > It seems that after commit 13c164b1a186 ("autofs: switch to
> > > kernel_write") there is now an extra LSM permission required (for
> > > the
> > > current task to write to the automount pipe) for processes
> > > accessing
> > > some yet-to-to-be mounted directory on which an autofs mount is
> > > set
> > > up. The call chain is:
> > > [...]
> > > autofs_wait() ->
> > > autofs_notify_daemon() ->
> > > autofs_write() ->
> > > kernel_write() ->
> > > rw_verify_area() ->
> > > security_file_permission()
> > >
> > > The bug report that led me to this commit is at [1].
> > >
> > > Technically, this is a regression for LSM users, since this is a
> > > kernel-internal operation and an LSM permission for the current
> > > task
> > > shouldn't be required. Can this patch be reverted? Perhaps
> > > __kernel_{read|write}() could instead be renamed to
> > > kernel_*_nocheck()
> > > so that the name is more descriptive?
> >
> > So we obviously should not break existing user space and need to
> > fix
> > this ASAP. The trivial "fix" would be to export __kernel_write
> > again
> > and switch autofs to use it. The other option would be a FMODE
> > flag
> > to bypass security checks, only to be set if the callers ensures
> > they've been valided (i.e. in autofs_prepare_pipe).
> >
> > Any opinions?
>
> Reexport for now. Incidentally, what is LSM doing rejecting writes
> into a pipe?
I had seen this too but thought it was due to selinux policy changes
but the previously linked bug shows the rejection is more widespread
than I thought.
A revert seems sensible for now but I'd like to understand why the
writes are being rejected too, I'll have a look around.
Ian
