[PATCH v5 11/23] security: Introduce inode_post_removexattr hook

Paul Moore paul at paul-moore.com
Mon Nov 20 20:55:54 UTC 2023


On Mon, Nov 20, 2023 at 1:04 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 11/20/2023 9:31 AM, Roberto Sassu wrote:
> > On Tue, 2023-11-07 at 09:33 -0800, Casey Schaufler wrote:
> >> On 11/7/2023 5:40 AM, Roberto Sassu wrote:
> >>> From: Roberto Sassu <roberto.sassu at huawei.com>
> >>>
> >>> In preparation for moving IMA and EVM to the LSM infrastructure, introduce
> >>> the inode_post_removexattr hook.
> >>>
> >>> At inode_removexattr hook, EVM verifies the file's existing HMAC value. At
> >>> inode_post_removexattr, EVM re-calculates the file's HMAC with the passed
> >>> xattr removed and other file metadata.
> >>>
> >>> Other LSMs could similarly take some action after successful xattr removal.
> >>>
> >>> The new hook cannot return an error and cannot cause the operation to be
> >>> reverted.
> >>>
> >>> Signed-off-by: Roberto Sassu <roberto.sassu at huawei.com>
> >>> Reviewed-by: Stefan Berger <stefanb at linux.ibm.com>
> >>> Reviewed-by: Mimi Zohar <zohar at linux.ibm.com>
> >>> ---
> >>>  fs/xattr.c                    |  9 +++++----
> >>>  include/linux/lsm_hook_defs.h |  2 ++
> >>>  include/linux/security.h      |  5 +++++
> >>>  security/security.c           | 14 ++++++++++++++
> >>>  4 files changed, 26 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/fs/xattr.c b/fs/xattr.c
> >>> index 09d927603433..84a4aa566c02 100644
> >>> --- a/fs/xattr.c
> >>> +++ b/fs/xattr.c
> >>> @@ -552,11 +552,12 @@ __vfs_removexattr_locked(struct mnt_idmap *idmap,
> >>>             goto out;
> >>>
> >>>     error = __vfs_removexattr(idmap, dentry, name);
> >>> +   if (error)
> >>> +           goto out;
> >> Shouldn't this be simply "return error" rather than a goto to nothing
> >> but "return error"?
> > I got a review from Andrew Morton. His argument seems convincing, that
> > having less return places makes the code easier to handle.
>
> That was in a case where you did more than just "return". Nonetheless,
> I think it's a matter of style that's not worth debating. Do as you will.

I'm not too bothered by this in the VFS code, that's up to the VFS
maintainers, but for future reference, in the LSM layer I really
dislike jumping to a label simply to return.

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list