Re: [PATCH] Adding the nfs4_secure_mounts bool

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3485 bytes --]

On Mon, 11 Nov 2013 15:33:14 -0500 Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Nov 11, 2013, at 1:59 PM, Steve Dickson <SteveD@redhat.com> wrote:
> 
> > On 11/11/13 13:30, Chuck Lever wrote:
> >> 
> >> On Nov 11, 2013, at 1:06 PM, Steve Dickson <SteveD@redhat.com> wrote:
> >> 
> >>> 
> >>> 
> >>> On 09/11/13 18:12, Myklebust, Trond wrote:
> >>>> One alternative to the above scheme, which I believe that I’ve 
> >>>> suggested before, is to have a permanent entry in rpc_pipefs 
> >>>> that rpc.gssd can open and that the kernel can use to detect 
> >>>> that it is running. If we make it /var/lib/nfs/rpc_pipefs/gssd/clnt00/gssd, 
> >>>> then AFAICS we don’t need to change nfs-utils at all, since all newer 
> >>>> versions of rpc.gssd will try to open for read anything of the form 
> >>>> /var/lib/nfs/rpc_pipefs/*/clntXX/gssd...
> >>> 
> >>> After further review I am going going have to disagree with you on this.
> >>> Since all the context is cached on the initial mount the kernel
> >>> should be using the call_usermodehelper() to call up to rpc.gssd 
> >>> to get the context, which means we could put this upcall noise 
> >>> to bed... forever! :-)
> >> 
> >> Ask Al Viro for his comments on whether the kernel should start 
> >> gssd (either a daemon or a script).  Hint: wear your kevlar underpants.
> > I was thinking gssd would become a the gssd-cmd command... Al does not
> > like the call_usermodehelper() interface?
> 
> He doesn't have a problem with call_usermodehelper() in general.  However, the kernel cannot guarantee security if it has to run a fixed command line.  Go ask him to explain.
> 
> 
> > 
> >> 
> >> Have you tried Trond's approach yet?
> > Looking into it... But nothing is trivial in that code... 
> > 
> >> 
> >>> I realize this is not going happen overnight, so I would still
> >>> like to propose my  nfs4_secure_mounts bool patch as bridge
> >>> to the new call_usermodehelper()  since its the cleanest 
> >>> solution so far... 
> >>> 
> >>> Thoughts?
> >> 
> >> We have workarounds already that work on every kernel since 3.8.
> >> 
> > The one that logs 5 to 20 lines (depending on thins are setup or not)
> > per mount? That does work in some environments but no all. ;-)
> 
> When does running rpc.gssd not work?

Oohh ooh.. Pick me.  Pick me!! I can answer that one.

Running rpc.gssd does not work if you are mounting a filesystem using the IP
address of the server and that IP address doesn't have a matching hostname
anywhere that can be found:

In a newly creating minimal kvm install without rpc.gssd running,
   mount 10.0.2.2:/home /mnt

sleeps for 15 seconds then succeeds.
If I start rpc.gssd, then the same command takes forever.

strace of rpc.gssd shows that it complains about not being able to resolve
the host name and "ERROR: failed to read service info".  Then it keeps the
pipes open but never sends any message on them, so the kernel just keeps on
waiting.

If I change "fail_keep_client" to "fail_destroy_client", then it closes the
pipe and we get the 15 second timeout back.
If I change  NI_NAMEREQD to 0, then the mount completes instantly.  (of course
that make serious compromise security so it was just for testing).
(Adding an entry to /etc/hosts also gives instant success).

I'm hoping that someone who understands this code will suggest something
clever so I don't have to dig through all of it ;-)

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]