Now that ecryptfs supports the get and set acl inode operations and the vfs has been switched to the new posi api, ecryptfs can simply rely on the stub posix acl handlers. Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
The current way of setting and getting posix acls through the generic xattr interface is error prone and type unsafe. The vfs needs to interpret and fixup posix acls before storing or reporting it to userspace. Various hacks exist to make this work. The code is hard to understand and difficult to maintain in it's current form. Instead of making this work by hacking posix acls through xattr handlers we are building a dedicated posix acl api around the get and set inode operations. This removes a lot of hackiness and makes the codepaths easier to maintain. A lot of background can be found in [1]. In order to build a type safe posix api around get and set acl we need all filesystem to implement get and set acl. So far ecryptfs didn't implement get and set acl inode operations because it wanted easy access to the dentry. Now that we extended the set acl inode operation to take a dentry argument and added a new get acl inode operation that takes a dentry argument we can let ecryptfs implement get and set acl inode operations. Note, until the vfs has been switched to the new posix acl api this patch is a non-functional change. Link: https://lore.kernel.org/all/20220801145520.1532837-1-brauner@kernel.org [1] Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
The current way of setting and getting posix acls through the generic xattr interface is error prone and type unsafe. The vfs needs to interpret and fixup posix acls before storing or reporting it to userspace. Various hacks exist to make this work. The code is hard to understand and difficult to maintain in it's current form. Instead of making this work by hacking posix acls through xattr handlers we are building a dedicated posix acl api around the get and set inode operations. This removes a lot of hackiness and makes the codepaths easier to maintain. A lot of background can be found in [1]. In order to build a type safe posix api around get and set acl we need all filesystem to implement get and set acl. So far ecryptfs didn't implement get and set acl inode operations because it wanted easy access to the dentry. Now that we extended the set acl inode operation to take a dentry argument and added a new get acl inode operation that takes a dentry argument we can let ecryptfs implement get and set acl inode operations. Note, until the vfs has been switched to the new posix acl api this patch is a non-functional change. Link: https://lore.kernel.org/all/20220801145520.1532837-1-brauner@kernel.org [1] Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Pull ecryptfs updates from Tyler Hicks: "Code cleanups and a bug fix - W=1 compiler warning cleanups - Mutex initialization simplification - Protect against NULL pointer exception during mount" * tag 'ecryptfs-5.13-rc1-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: ecryptfs: fix kernel panic with null dev_name ecryptfs: remove unused helpers ecryptfs: Fix typo in message eCryptfs: Use DEFINE_MUTEX() for mutex lock ecryptfs: keystore: Fix some kernel-doc issues and demote non-conformant headers ecryptfs: inode: Help out nearly-there header and demote non-conformant ones ecryptfs: mmap: Help out one function header and demote other abuses ecryptfs: crypto: Supply some missing param descriptions and demote abuses ecryptfs: miscdev: File headers are not good kernel-doc candidates ecryptfs: main: Demote a bunch of non-conformant kernel-doc headers ecryptfs: messaging: Add missing param descriptions and demote abuses ecryptfs: super: Fix formatting, naming and kernel-doc abuses ecryptfs: file: Demote kernel-doc abuses ecryptfs: kthread: Demote file header and provide description for 'cred' ecryptfs: dentry: File headers are not good candidates for kernel-doc ecryptfs: debug: Demote a couple of kernel-doc abuses ecryptfs: read_write: File headers do not make good candidates for kernel-doc ecryptfs: use DEFINE_MUTEX() for mutex lock eCryptfs: add a semicolon
Pull exryptfs updates from Al Viro: "The interesting part here is (ecryptfs) lock_parent() fixes - its treatment of ->d_parent had been very wrong. The rest is trivial cleanups" * 'work.ecryptfs' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ecryptfs: ecryptfs_dentry_info->crypt_stat is never used ecryptfs: get rid of unused accessors ecryptfs: saner API for lock_parent() ecryptfs: get rid of pointless dget/dput in ->symlink() and ->link()
Fixes the following W=1 kernel build warning(s): fs/ecryptfs/inode.c:27: warning: Function parameter or member 'dentry' not described in 'lock_parent' fs/ecryptfs/inode.c:27: warning: Function parameter or member 'lower_dentry' not described in 'lock_parent' fs/ecryptfs/inode.c:27: warning: Function parameter or member 'lower_dir' not described in 'lock_parent' fs/ecryptfs/inode.c:27: warning: expecting prototype for eCryptfs(). Prototype was for lock_parent() instead fs/ecryptfs/inode.c:211: warning: Function parameter or member 'ecryptfs_dentry' not described in 'ecryptfs_initialize_file' fs/ecryptfs/inode.c:211: warning: Function parameter or member 'ecryptfs_inode' not described in 'ecryptfs_initialize_file' fs/ecryptfs/inode.c:258: warning: Function parameter or member 'mnt_userns' not described in 'ecryptfs_create' fs/ecryptfs/inode.c:258: warning: Function parameter or member 'directory_inode' not described in 'ecryptfs_create' fs/ecryptfs/inode.c:258: warning: Function parameter or member 'ecryptfs_dentry' not described in 'ecryptfs_create' fs/ecryptfs/inode.c:258: warning: Function parameter or member 'excl' not described in 'ecryptfs_create' fs/ecryptfs/inode.c:258: warning: Excess function parameter 'dir' description in 'ecryptfs_create' fs/ecryptfs/inode.c:258: warning: Excess function parameter 'dentry' description in 'ecryptfs_create' fs/ecryptfs/inode.c:320: warning: Function parameter or member 'dentry' not described in 'ecryptfs_lookup_interpose' fs/ecryptfs/inode.c:320: warning: Function parameter or member 'lower_dentry' not described in 'ecryptfs_lookup_interpose' fs/ecryptfs/inode.c:887: warning: Function parameter or member 'mnt_userns' not described in 'ecryptfs_setattr' Cc: Tyler Hicks <code@tyhicks.com> Cc: "Michael A. Halcrow" <mahalcro@us.ibm.com> Cc: "Michael C. Thompsion" <mcthomps@us.ibm.com> Cc: ecryptfs@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Tyler Hicks <code@tyhicks.com>
Add stacking for the fileattr operations. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Cc: Tyler Hicks <code@tyhicks.com>
Switch all users of lock_parent() to the approach used by ->unlink() and ->rmdir() - instead of playing with dget_parent() of underlying dentry of child, * start with ecryptfs dentry of child. * find underlying dentries for that dentry and its parent (which is stable, since the parent directory in upper layer is held at least shared). No need to pin them, they are already pinned by ecryptfs dentries. * lock the inode of undelying directory of parent * check if it's the parent of underlying dentry of child. ->d_parent of underlying dentry of child might be unstable. However, result of its comparison with underlying dentry of parent *is* stable now. Turn that into replacement of lock_parent(), convert the existing callers of lock_parent() to that, along with ecryptfs_unlink() and ecryptfs_rmdir(). Callers need only the underlying dentry of child and inode of underlying dentry of parent, so lock_parent() passes those to the caller now. Note that underlying directory is locked in any case, success or failure. That approach does not need a primitive for unlocking - we hadn't grabbed any dentry references, so all we need is to unlock the underlying directory inode. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
calls in ->unlink(), ->rmdir() and ->rename() make sense - we want to prevent the underlying dentries going negative there. In ->symlink() and ->link() they are absolutely pointless. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>