On Thu, Nov 29, 2012 at 09:02:49PM -0500, David Quigley wrote:
> On 11/29/2012 20:50, Casey Schaufler wrote:
> >On 11/29/2012 4:46 PM, David Quigley wrote:
> >>On 11/29/2012 19:34, Casey Schaufler wrote:
> >>>I would think that were it not for the case that access is denied
> >>>and I get an audit record for nfsd that reports a subject
> >>>label of "_"
> >>>(which is correct for nfsd but not the process attempting
> >>>access) and
> >>>an object label of "WhooHoo", which is correct. The server side
> >>>looks like it might be working right, given the information that it
> >>>has.
> >>>
> >>
> >>Ok so this is the problem. nfsd is a kernel thread I believe. In
> >>SELinux land it has the type kernel_t which is all powerful. We
> >>don't
> >>have client label transport yet (That requires RPCSECGSSv3). Is
> >>there
> >>a way you can have that kernel thread running as a type that has
> >>access to everything?
> >
> >That would be having CAP_MAC_ADMIN and CAP_MAC_OVERRIDE in Smackese.
> >Looking at /proc/<pid-of-nfsd>/status we see CapEff of fff...fff
> >which
> >is to say, all capabilities.
> >
>
> Hmm thats interesting then. You could try using rpcdebug -m nfsd to
> turn on some of the debugging to look around the internals and
> figure out whats going on. If you pass -v it will give you all of
> the potential flags.
>
> >
> >>I think that is the current problem. Which makes perfect sense. If
> >>your kernel threads don't get started with max privilege then the
> >>server would be denied access on all of the file attributes and
> >>wouldn't be able to ship it over the wire properly.
> >
> >OK. I haven't had to do anything with kernel threads so far.
> >Where is NFS setting these up? Poking around fs/nfsd looks like
> >the place, but I haven't seen anything there that makes it look
> >like they would be running without capabilities. Clearly, that's
> >what I'm seeing. It looks as if the credential of nfsd does not
> >match what /proc reports. Bother.
> >
>
> I'm not entirely sure whats up either. If you want to look for the
> NFSd threads they are in fs/nfsd/nfssvc.c. The main function starts
> on line 487.
I'm not following the discussion, but: maybe you want to look at
fs/nfsd/auth.c:nfsd_setuser() ? In particular, the
cap_{drop/raise}_nfsd_set() calls at the end.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
