linux.git/fs/ecryptfs/inode.c, branch v6.8

Merge tag 'pull-rename' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2024-01-12T04:00:22+00:00

Pull rename updates from Al Viro:
 "Fix directory locking scheme on rename

  This was broken in 6.5; we really can't lock two unrelated directories
  without holding ->s_vfs_rename_mutex first and in case of same-parent
  rename of a subdirectory 6.5 ends up doing just that"

* tag 'pull-rename' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  rename(): avoid a deadlock in the case of parents having no common ancestor
  kill lock_two_inodes()
  rename(): fix the locking of subdirectories
  f2fs: Avoid reading renamed directory if parent does not change
  ext4: don't access the source subdirectory content on same-directory rename
  ext2: Avoid reading renamed directory if parent does not change
  udf_rename(): only access the child content on cross-directory rename
  ocfs2: Avoid touching renamed directory if parent does not change
  reiserfs: Avoid touching renamed directory if parent does not change

Merge tag 'unicode-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/krisman/unicode

2024-01-11T00:06:58+00:00

Pull unicode updates from Gabriel Krisman Bertazi:
 "Other than the update to MAINTAINERS, this PR has only a fix to stop
  ecryptfs from inadvertently mounting case-insensitive filesystems that
  it cannot handle, which would otherwise caused post-mount failures"

* tag 'unicode-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/krisman/unicode:
  MAINTAINERS: update unicode maintainer e-mail address
  ecryptfs: Reject casefold directory inodes

ecryptfs: Reject casefold directory inodes

2024-01-08T19:34:43+00:00

Even though it seems to be able to resolve some names of
case-insensitive directories, the lack of d_hash and d_compare means we
end up with a broken state in the d_cache.  Considering it was never a
goal to support these two together, and we are preparing to use
d_revalidate in case-insensitive filesystems, which would make the
combination even more broken, reject any attempt to get a casefolded
inode from ecryptfs.

Signed-off-by: Gabriel Krisman Bertazi 
Reviewed-by: Eric Biggers

rename(): avoid a deadlock in the case of parents having no common ancestor

2023-11-25T07:54:14+00:00

... and fix the directory locking documentation and proof of correctness.
Holding ->s_vfs_rename_mutex *almost* prevents ->d_parent changes; the
case where we really don't want it is splicing the root of disconnected
tree to somewhere.

In other words, ->s_vfs_rename_mutex is sufficient to stabilize "X is an
ancestor of Y" only if X and Y are already in the same tree.  Otherwise
it can go from false to true, and one can construct a deadlock on that.

Make lock_two_directories() report an error in such case and update the
callers of lock_rename()/lock_rename_child() to handle such errors.

And yes, such conditions are not impossible to create ;-/

Reviewed-by: Jan Kara 
Signed-off-by: Al Viro

fs: Pass AT_GETATTR_NOSEC flag to getattr interface function

2023-11-18T13:54:07+00:00

When vfs_getattr_nosec() calls a filesystem's getattr interface function
then the 'nosec' should propagate into this function so that
vfs_getattr_nosec() can again be called from the filesystem's gettattr
rather than vfs_getattr(). The latter would add unnecessary security
checks that the initial vfs_getattr_nosec() call wanted to avoid.
Therefore, introduce the getattr flag GETATTR_NOSEC and allow to pass
with the new getattr_flags parameter to the getattr interface function.
In overlayfs and ecryptfs use this flag to determine which one of the
two functions to call.

In a recent code change introduced to IMA vfs_getattr_nosec() ended up
calling vfs_getattr() in overlayfs, which in turn called
security_inode_getattr() on an exiting process that did not have
current->fs set anymore, which then caused a kernel NULL pointer
dereference. With this change the call to security_inode_getattr() can
be avoided, thus avoiding the NULL pointer dereference.

Reported-by: 
Fixes: db1d1e8b9867 ("IMA: use vfs_getattr_nosec to get the i_version")
Cc: Alexander Viro 
Cc: 
Cc: Miklos Szeredi 
Cc: Amir Goldstein 
Cc: Tyler Hicks 
Cc: Mimi Zohar 
Suggested-by: Christian Brauner 
Co-developed-by: Amir Goldstein 
Signed-off-by: Stefan Berger 
Link: https://lore.kernel.org/r/20231002125733.1251467-1-stefanb@linux.vnet.ibm.com
Reviewed-by: Amir Goldstein 
Signed-off-by: Christian Brauner

ecryptfs: move ecryptfs_xattr_handlers to .rodata

2023-10-09T14:24:17+00:00

This makes it harder for accidental or malicious changes to
ecryptfs_xattr_handlers at runtime.

Cc: Tyler Hicks 
Cc: ecryptfs@vger.kernel.org
Signed-off-by: Wedson Almeida Filho 
Link: https://lore.kernel.org/r/20230930050033.41174-8-wedsonaf@gmail.com
Signed-off-by: Christian Brauner

fs: pass the request_mask to generic_fillattr

2023-08-09T06:56:36+00:00

generic_fillattr just fills in the entire stat struct indiscriminately
today, copying data from the inode. There is at least one attribute
(STATX_CHANGE_COOKIE) that can have side effects when it is reported,
and we're looking at adding more with the addition of multigrain
timestamps.

Add a request_mask argument to generic_fillattr and have most callers
just pass in the value that is passed to getattr. Have other callers
(e.g. ksmbd) just pass in STATX_BASIC_STATS. Also move the setting of
STATX_CHANGE_COOKIE into generic_fillattr.

Acked-by: Joseph Qi 
Reviewed-by: Xiubo Li 
Reviewed-by: "Paulo Alcantara (SUSE)" 
Reviewed-by: Jan Kara 
Signed-off-by: Jeff Layton 
Message-Id: <20230807-mgctime-v7-2-d1dec143a704@kernel.org>
Signed-off-by: Christian Brauner

ecryptfs: convert to ctime accessor functions

2023-07-13T08:28:06+00:00

In later patches, we're going to change how the inode's ctime field is
used. Switch to using accessor functions instead of raw accesses of
inode->i_ctime.

Signed-off-by: Jeff Layton 
Reviewed-by: Jan Kara 
Message-Id: <20230705190309.579783-34-jlayton@kernel.org>
Signed-off-by: Christian Brauner

fs: drop unused posix acl handlers

2023-03-06T08:57:12+00:00

Remove struct posix_acl_{access,default}_handler for all filesystems
that don't depend on the xattr handler in their inode->i_op->listxattr()
method in any way. There's nothing more to do than to simply remove the
handler. It's been effectively unused ever since we introduced the new
posix acl api.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner (Microsoft)

fs: port xattr to mnt_idmap

2023-01-19T08:24:28+00:00

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner (Microsoft)