From: "J. Bruce Fields" <bfields@fieldses.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Jeff Layton <jlayton@poochiereds.net>,
trond.myklebust@primarydata.com, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH] sunrpc: make debugfs file creation failure non-fatal
Date: Tue, 31 Mar 2015 11:30:06 -0400 [thread overview]
Message-ID: <20150331153006.GK6901@fieldses.org> (raw)
In-Reply-To: <20150331142641.GA9961@kroah.com>
On Tue, Mar 31, 2015 at 04:26:41PM +0200, Greg KH wrote:
> On Tue, Mar 31, 2015 at 10:09:16AM -0400, J. Bruce Fields wrote:
> > On Mon, Mar 30, 2015 at 07:47:53PM -0400, J. Bruce Fields wrote:
> > > ACK.--b.
> >
> > But note the result after this is that the debugfs directories will
> > always miss gss-proxy clients on selinux-enforcing systems. That could
> > be really confusing.
>
> So, you shouldn't be relying on debugfs :)
>
> > So we should still fix debugfs's permission checking. It doesn't make
> > sense to me as is.
>
> I don't really understand what the problem is here. Is selinux
> preventing some debugfs files to be created?
debugfs doesn't actually check permission on the create itself, it only
checks for permission to lookup in the directory. But the effect is to
prevent some creates, yes.
> If so, great, it's allowed
> to do that, go fix up your selinux config files to not do that.
> Otherwise, to go around selinux/LSM seems like a bad idea for debugfs to
> be doing, don't you think?
As far as I can tell, other synthetic filesystems that allow kernel
subsystems to create files skip permissions checking (based on just a
quick look at proc, sysfs, and rpc_pipefs). Even in the debugfs case
the permissions-checking appears to be an accident.
To take an extreme case, we wouldn't want fork() to check the caller's
permissions on /proc.
It's less crazy in this case, but I think it still violates the the
principle of least surprise.
If there's some real requirement for permissions checking here, then I'd
like to understand what that requirement is. And then:
- create should be checking for the correct permissions (not
just search/execute).
- we should document that callers need to ignore errors from
debugfs_create_*, to avoid situations like this where adding
debugging files to some bit of kernel infrastructure causes
regressions. ("You need to update your selinux policy to
access this new debugging feature" is maybe OK, but "You need
to update your selinux policy to fix a kernel regression"
definitely isn't.)
--b.
prev parent reply other threads:[~2015-03-31 15:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 21:58 [PATCH] sunrpc: make debugfs file creation failure non-fatal Jeff Layton
2015-03-30 23:47 ` J. Bruce Fields
2015-03-30 23:47 ` J. Bruce Fields
2015-03-31 14:09 ` J. Bruce Fields
2015-03-31 14:26 ` Greg KH
2015-03-31 15:11 ` Jeff Layton
2015-03-31 15:48 ` Boaz Harrosh
2015-03-31 15:58 ` J. Bruce Fields
2015-03-31 15:30 ` J. Bruce Fields [this message]
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=20150331153006.GK6901@fieldses.org \
--to=bfields@fieldses.org \
--cc=gregkh@linuxfoundation.org \
--cc=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.