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:

quoted

[adding Linus and Al]

On Mon, Sep 21, 2020 at 04:51:35PM +0200, Ondrej Mosnacek wrote:

quoted

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