linux.git/fs/fuse/dir.c, branch v5.12

fs: make helpers idmap mount aware

2021-01-24T13:27:20+00:00

Extend some inode methods with an additional user namespace argument. A
filesystem that is aware of idmapped mounts will receive the user
namespace the mount has been marked with. This can be used for
additional permission checking and also to enable filesystems to
translate between uids and gids if they need to. We have implemented all
relevant helpers in earlier patches.

As requested we simply extend the exisiting inode method instead of
introducing new ones. This is a little more code churn but it's mostly
mechanical and doesnt't leave us with additional inode methods.

Link: https://lore.kernel.org/r/20210121131959.646623-25-christian.brauner@ubuntu.com
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner

stat: handle idmapped mounts

2021-01-24T13:27:17+00:00

The generic_fillattr() helper fills in the basic attributes associated
with an inode. Enable it to handle idmapped mounts. If the inode is
accessed through an idmapped mount map it into the mount's user
namespace before we store the uid and gid. If the initial user namespace
is passed nothing changes so non-idmapped mounts will see identical
behavior as before.

Link: https://lore.kernel.org/r/20210121131959.646623-12-christian.brauner@ubuntu.com
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Reviewed-by: James Morris 
Signed-off-by: Christian Brauner

attr: handle idmapped mounts

2021-01-24T13:27:16+00:00

When file attributes are changed most filesystems rely on the
setattr_prepare(), setattr_copy(), and notify_change() helpers for
initialization and permission checking. Let them handle idmapped mounts.
If the inode is accessed through an idmapped mount map it into the
mount's user namespace. Afterwards the checks are identical to
non-idmapped mounts. If the initial user namespace is passed nothing
changes so non-idmapped mounts will see identical behavior as before.

Helpers that perform checks on the ia_uid and ia_gid fields in struct
iattr assume that ia_uid and ia_gid are intended values and have already
been mapped correctly at the userspace-kernelspace boundary as we
already do today. If the initial user namespace is passed nothing
changes so non-idmapped mounts will see identical behavior as before.

Link: https://lore.kernel.org/r/20210121131959.646623-8-christian.brauner@ubuntu.com
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner

namei: make permission helpers idmapped mount aware

2021-01-24T13:27:16+00:00

The two helpers inode_permission() and generic_permission() are used by
the vfs to perform basic permission checking by verifying that the
caller is privileged over an inode. In order to handle idmapped mounts
we extend the two helpers with an additional user namespace argument.
On idmapped mounts the two helpers will make sure to map the inode
according to the mount's user namespace and then peform identical
permission checks to inode_permission() and generic_permission(). If the
initial user namespace is passed nothing changes so non-idmapped mounts
will see identical behavior as before.

Link: https://lore.kernel.org/r/20210121131959.646623-6-christian.brauner@ubuntu.com
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig 
Reviewed-by: James Morris 
Acked-by: Serge Hallyn 
Signed-off-by: Christian Brauner

fuse: fix bad inode

2020-12-10T14:33:14+00:00

Jan Kara's analysis of the syzbot report (edited):

  The reproducer opens a directory on FUSE filesystem, it then attaches
  dnotify mark to the open directory.  After that a fuse_do_getattr() call
  finds that attributes returned by the server are inconsistent, and calls
  make_bad_inode() which, among other things does:

          inode->i_mode = S_IFREG;

  This then confuses dnotify which doesn't tear down its structures
  properly and eventually crashes.

Avoid calling make_bad_inode() on a live inode: switch to a private flag on
the fuse inode.  Also add the test to ops which the bad_inode_ops would
have caught.

This bug goes back to the initial merge of fuse in 2.6.14...

Reported-by: syzbot+f427adf9324b92652ccc@syzkaller.appspotmail.com
Signed-off-by: Miklos Szeredi 
Tested-by: Jan Kara 
Cc:

fuse: add a flag FUSE_OPEN_KILL_SUIDGID for open() request

2020-11-11T16:22:33+00:00

With FUSE_HANDLE_KILLPRIV_V2 support, server will need to kill suid/sgid/
security.capability on open(O_TRUNC), if server supports
FUSE_ATOMIC_O_TRUNC.

But server needs to kill suid/sgid only if caller does not have CAP_FSETID.
Given server does not have this information, client needs to send this info
to server.

So add a flag FUSE_OPEN_KILL_SUIDGID to fuse_open_in request which tells
server to kill suid/sgid (only if group execute is set).

This flag is added to the FUSE_OPEN request, as well as the FUSE_CREATE
request if the create was non-exclusive, since that might result in an
existing file being opened/truncated.

Signed-off-by: Vivek Goyal 
Signed-off-by: Miklos Szeredi

fuse: don't send ATTR_MODE to kill suid/sgid for handle_killpriv_v2

2020-11-11T16:22:33+00:00

If client does a write() on a suid/sgid file, VFS will first call
fuse_setattr() with ATTR_KILL_S[UG]ID set.  This requires sending setattr
to file server with ATTR_MODE set to kill suid/sgid.  But to do that client
needs to know latest mode otherwise it is racy.

To reduce the race window, current code first call fuse_do_getattr() to get
latest ->i_mode and then resets suid/sgid bits and sends rest to server
with setattr(ATTR_MODE).  This does not reduce the race completely but
narrows race window significantly.

With fc->handle_killpriv_v2 enabled, it should be possible to remove this
race completely.  Do not kill suid/sgid with ATTR_MODE at all.  It will be
killed by server when WRITE request is sent to server soon.  This is
similar to fc->handle_killpriv logic.  V2 is just more refined version of
protocol.  Hence this patch does not send ATTR_MODE to kill suid/sgid if
fc->handle_killpriv_v2 is enabled.

This creates an issue if fc->writeback_cache is enabled.  In that case
WRITE can be cached in guest and server might not see WRITE request and
hence will not kill suid/sgid.  Miklos suggested that in such cases, we
should fallback to a writethrough WRITE instead and that will generate
WRITE request and kill suid/sgid.  This patch implements that too.

But this relies on client seeing the suid/sgid set.  If another client sets
suid/sgid and this client does not see it immideately, then we will not
fallback to writethrough WRITE.  So this is one limitation with both
fc->handle_killpriv_v2 and fc->writeback_cache enabled.  Both the options
are not fully compatible.  But might be good enough for many use cases.

Note: This patch is not checking whether security.capability is set or not
      when falling back to writethrough path.  If suid/sgid is not set and
      only security.capability is set, that will be taken care of by
      file_remove_privs() call in ->writeback_cache path.

Signed-off-by: Vivek Goyal 
Signed-off-by: Miklos Szeredi

fuse: setattr should set FATTR_KILL_SUIDGID

2020-11-11T16:22:33+00:00

If fc->handle_killpriv_v2 is enabled, we expect file server to clear
suid/sgid/security.capbility upon chown/truncate/write as appropriate.

Upon truncate (ATTR_SIZE), suid/sgid are cleared only if caller does not
have CAP_FSETID.  File server does not know whether caller has CAP_FSETID
or not.  Hence set FATTR_KILL_SUIDGID upon truncate to let file server know
that caller does not have CAP_FSETID and it should kill suid/sgid as
appropriate.

On chown (ATTR_UID/ATTR_GID) suid/sgid need to be cleared irrespective of
capabilities of calling process, so set FATTR_KILL_SUIDGID unconditionally
in that case.

Signed-off-by: Vivek Goyal 
Signed-off-by: Miklos Szeredi

fuse: always revalidate if exclusive create

2020-11-11T16:22:32+00:00

Failure to do so may result in EEXIST even if the file only exists in the
cache and not in the filesystem.

The atomic nature of O_EXCL mandates that the cached state should be
ignored and existence verified anew.

Reported-by: Ken Schalk 
Signed-off-by: Miklos Szeredi

fuse: get rid of fuse_mount refcount

2020-11-11T16:22:32+00:00

Fuse mount now only ever has a refcount of one (before being freed) so the
count field is unnecessary.

Remove the refcounting and fold fuse_mount_put() into callers.  The only
caller of fuse_mount_put() where fm->fc was NULL is fuse_dentry_automount()
and here the fuse_conn_put() can simply be omitted.

Signed-off-by: Miklos Szeredi