All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Chris Siebenmann <cks@cs.toronto.edu>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: Best approach for authenticating hosts for NFS (v3)?
Date: Wed, 05 Nov 2014 15:21:21 -0500	[thread overview]
Message-ID: <545A86C1.4090809@RedHat.com> (raw)
In-Reply-To: <20141105164555.3958A400746@apps1.cs.toronto.edu>



On 11/05/2014 11:45 AM, Chris Siebenmann wrote:
>> On 11/04/2014 11:53 AM, Chris Siebenmann wrote:
>>> PS: 'switch to NFS v4 to strongly authenticate user requests' is not an
>>>     option for us. We specifically value things that cannot be done
>>>     with true verification of user identification, like cron, and we
>>>     don't have and don't want to build the infrastructure that would
>>>     be required for strongly authenticated NFS v4.
>> The exact same "strongly authenticate" that in v4 is available
>> with v3. NFS secure mounts (-o krb5) are available 
>> with all NFS protocol versions.
>>
>> Tying NFS secure mounts with an FreeIPA environment should work
>> out well..    
> 
>  NFS v4 isn't the problem; strong authentication of user identities (and
> Kerberos) is the problem. Our environment and our users rely on the many
> forms that setuid takes[*] and as far as I know those are impossible with
> strong identification (in any NFS or remote filesystem protocol) because
> the point of strong authentication is that the server no longer trusts
> clients when they say 'honest, I'm working on behalf of uid <X>'.
Gotta... Interesting... I was just talking to a customer about 
this very problem...  Not being able to tie multiple GSS contexts 
to a single uid... 

steved.
> 
> (Instead the client must prove it by presenting a secret only the user
> is supposed to have access to, which the user must have somehow loaded
> on the client.)
> 
> 	- cks
> [*: including but not limited to crontabs, .forward files, user run web
>     apps and CGI-BINs, and detached processes left running for weeks.
> ]
> 

  reply	other threads:[~2014-11-05 20:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04 16:53 Best approach for authenticating hosts for NFS (v3)? Chris Siebenmann
2014-11-05  8:56 ` Christoph Hellwig
2014-11-05 16:32 ` Steve Dickson
2014-11-05 16:45   ` Chris Siebenmann
2014-11-05 20:21     ` Steve Dickson [this message]
2014-11-09 20:50     ` Simo Sorce

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=545A86C1.4090809@RedHat.com \
    --to=steved@redhat.com \
    --cc=cks@cs.toronto.edu \
    --cc=linux-nfs@vger.kernel.org \
    /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.