[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2d5b27847fde03e0b4b9fc7a464fd87@paul-moore.com>
Date: Fri, 21 Mar 2025 17:32:25 -0400
From: Paul Moore <paul@...l-moore.com>
To: Andrey Albershteyn <aalbersh@...hat.com>, Richard Henderson <richard.henderson@...aro.org>,
Matt Turner <mattst88@...il.com>, Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>, Michal Simek <monstr@...str.eu>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>, Helge Deller <deller@....de>,
Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>,
Naveen N Rao <naveen@...nel.org>, Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>, Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
"David S. Miller" <davem@...emloft.net>, Andreas Larsson <andreas@...sler.com>,
Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Chris Zankel <chris@...kel.net>, Max Filippov <jcmvbkbc@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Mickaël Salaün <mic@...ikod.net>,
Günther Noack <gnoack@...gle.com>,
Arnd Bergmann <arnd@...db.de>, Pali Rohár <pali@...nel.org>,
James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>
Cc: linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, linux-sh@...r.kernel.org, sparclinux@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org, linux-api@...r.kernel.org, linux-arch@...r.kernel.org, selinux@...r.kernel.org, Andrey Albershteyn <aalbersh@...nel.org>
Subject: Re: [PATCH v4 1/3] lsm: introduce new hooks for setting/getting inode fsxattr
On Mar 21, 2025 Andrey Albershteyn <aalbersh@...hat.com> wrote:
>
> Introduce new hooks for setting and getting filesystem extended
> attributes on inode (FS_IOC_FSGETXATTR).
>
> Cc: selinux@...r.kernel.org
> Cc: Paul Moore <paul@...l-moore.com>
>
> Signed-off-by: Andrey Albershteyn <aalbersh@...nel.org>
> ---
> fs/ioctl.c | 7 ++++++-
> include/linux/lsm_hook_defs.h | 4 ++++
> include/linux/security.h | 16 ++++++++++++++++
> security/security.c | 32 ++++++++++++++++++++++++++++++++
> 4 files changed, 58 insertions(+), 1 deletion(-)
Thanks Andrey, one small change below, but otherwise this looks pretty
good. If you feel like trying to work up the SELinux implementation but
need some assitance please let me know, I'll be happy to help :)
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 638a36be31c14afc66a7fd6eb237d9545e8ad997..4434c97bc5dff5a3e8635e28745cd99404ff353e 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -525,10 +525,15 @@ EXPORT_SYMBOL(fileattr_fill_flags);
> int vfs_fileattr_get(struct dentry *dentry, struct fileattr *fa)
> {
> struct inode *inode = d_inode(dentry);
> + int error;
>
> if (!inode->i_op->fileattr_get)
> return -ENOIOCTLCMD;
>
> + error = security_inode_getfsxattr(inode, fa);
> + if (error)
> + return error;
> +
> return inode->i_op->fileattr_get(dentry, fa);
> }
> EXPORT_SYMBOL(vfs_fileattr_get);
> @@ -692,7 +697,7 @@ int vfs_fileattr_set(struct mnt_idmap *idmap, struct dentry *dentry,
> fa->flags |= old_ma.flags & ~FS_COMMON_FL;
> }
> err = fileattr_set_prepare(inode, &old_ma, fa);
> - if (!err)
> + if (!err && !security_inode_setfsxattr(inode, fa))
> err = inode->i_op->fileattr_set(idmap, dentry, fa);
> }
> inode_unlock(inode);
I don't believe we want to hide or otherwise drop the LSM return code as
that could lead to odd behavior, e.g. returning 0/success despite not
having executed the fileattr_set operation.
--
paul-moore.com
Powered by blists - more mailing lists