From: Al Viro <viro@zeniv.linux.org.uk>
To: James Morris <jmorris@namei.org>
Cc: Kangjie Lu <kjlu@umn.edu>,
pakki001@umn.edu, "Serge E. Hallyn" <serge@hallyn.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] security: inode: fix a missing check for securityfs_create_file
Date: Wed, 10 Apr 2019 19:01:57 +0100 [thread overview]
Message-ID: <20190410180156.GZ2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <alpine.LRH.2.21.1904110334380.25754@namei.org>
On Thu, Apr 11, 2019 at 03:34:43AM +1000, James Morris wrote:
> On Fri, 15 Mar 2019, Kangjie Lu wrote:
>
> > securityfs_create_file may fail. The fix checks its status and
> > returns the error code upstream if it fails.
> >
> > Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> >
>
> Applied to
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
>
> > ---
> > Return the exact error code upstream.
> > ---
> > security/inode.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/security/inode.c b/security/inode.c
> > index b7772a9b315e..667f8b15027d 100644
> > --- a/security/inode.c
> > +++ b/security/inode.c
> > @@ -339,6 +339,11 @@ static int __init securityfs_init(void)
> > #ifdef CONFIG_SECURITY
> > lsm_dentry = securityfs_create_file("lsm", 0444, NULL, NULL,
> > &lsm_ops);
> > + if (IS_ERR(lsm_dentry)) {
> > + unregister_filesystem(&fs_type);
> > + sysfs_remove_mount_point(kernel_kobj, "security");
> > + return PTR_ERR(lsm_dentry);
> > + }
Rather bad way to do it - generally, register_filesystem() should be
the last thing done by initialization. Any modular code that
does unregister_filesystem() on failure exit is flat-out broken;
here it's not instantly FUBAR, but it's a bloody bad example.
What's more, why not let simple_fill_super() do it? Just
static int fill_super(struct super_block *sb, void *data, int silent)
{
static const struct tree_descr files[] = {
#ifdef CONFIG_SECURITY
{"lsm", &lsm_ops, 0444},
#endif
{""}
};
and to hell with that call of securityfs_create_file() and all its
failure handling...
next prev parent reply other threads:[~2019-04-10 18:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 4:09 [PATCH] security: inode: fix a missing check for securityfs_create_file Kangjie Lu
2019-03-15 19:08 ` James Morris
2019-03-15 21:00 ` Kangjie Lu
2019-03-15 22:34 ` Tetsuo Handa
2019-04-10 17:34 ` James Morris
2019-04-10 18:01 ` Al Viro [this message]
2019-04-10 22:00 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190410180156.GZ2217@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=jmorris@namei.org \
--cc=kjlu@umn.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pakki001@umn.edu \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).