On Tue, 31 Mar 2015 16:26:41 +0200 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
