Re: [PATCH] sunrpc: make debugfs file creation failure non-fatal

[Jeff Layton <jlayton@poochiereds.net>]

On Tue, 31 Mar 2015 16:26:41 +0200
Greg KH <gregkh@linuxfoundation.org> 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 :)
> 

These files are nice to have things for debugging, so debugfs seemed
like the appropriate place for them.

> > 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?  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?
>

gssproxy is SELinux contained and the current policy forbids it from
creating the debugfs files. gssproxy isn't actually creating them
directly however -- the kernel is creating them as a side effect of the
rpc_clnt/rpc_xprt creation.

The question is whether enforcing SELinux policy on debugfs files makes
any sense at all. AFAICT, userland can't really create files directly
on debugfs, can it? So why should we prevent the kernel from doing so
just because it happens to be occurring in the context of a contained
SELinux process?

We certainly can update the selinux policy to allow gssproxy to do
this, but:

a) it's a pain

...and..

b) it seems like we're working around nonsensical debugfs behavior


-- 
Jeff Layton <jlayton@poochiereds.net>