From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Per Olofsson <pelle@dsv.su.se>, Paul Jakma <paul@clubi.ie>,
nfs@lists.sourceforge.net
Subject: Re: NFSv3+Krb5 and mountd
Date: Mon, 30 Aug 2004 13:17:34 -0400 [thread overview]
Message-ID: <20040830171734.GC1555@fieldses.org> (raw)
In-Reply-To: <1093884302.8729.21.camel@lade.trondhjem.org>
On Mon, Aug 30, 2004 at 12:45:02PM -0400, Trond Myklebust wrote:
> På må , 30/08/2004 klokka 11:45, skreiv Per Olofsson:
>
> > OK, I understand. I don't really need authenticated mount requests
> > though, I only need authenticated file system accesses. In other
> > words, I don't care who mounts the file system as long as they can't
> > impersonate a user without a valid ticket. Is this easier to
> > implement? Does it have any other security implications?
>
> This is already implemented...
>
> The RPCSEC_GSS implementation that is in linux-2.6.x already follows the
> guidelines in RFC2623 when you mount an NFSv2 or v3 partition.
I believe (can't find the right language now) that RFC2623 says it's OK
for the server to allow the client to do MOUNT requests and a few
filesystem requests (sufficient for statfs) without rpcsec_gss, even on
rpcsec_gss exports. Our server and mountd currently do *not* do that.
Since they also don't support rpcsec_gss, that means we're in the
unfortunate position that the only practical way to mount an nfsv2/3
filesystem with krb5 right now is to first make sure the filesystem is
also exported to the client (read-only should suffice) via auth_sys.
I think that adding rpcsec_gss support to the userland utilities, and
making it easy for people to distribute keytabs to their clients, is the
better long-term solution than enabling RFC2623's workarounds. But
maybe too many clients already expect to be able to mount with auth_sys
only.
--b.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-08-30 17:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-24 18:41 NFSv3+Krb5 and mountd Per Olofsson
2004-08-30 1:41 ` Paul Jakma
2004-08-30 2:01 ` J. Bruce Fields
2004-08-30 15:45 ` Per Olofsson
2004-08-30 16:45 ` Trond Myklebust
2004-08-30 17:17 ` J. Bruce Fields [this message]
2004-08-30 17:45 ` Trond Myklebust
2004-08-30 18:04 ` J. Bruce Fields
2004-08-30 22:25 ` Trond Myklebust
2004-09-02 15:39 ` J. Bruce Fields
2004-08-30 21:54 ` Per Olofsson
2004-08-30 21:25 ` Per Olofsson
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=20040830171734.GC1555@fieldses.org \
--to=bfields@fieldses.org \
--cc=nfs@lists.sourceforge.net \
--cc=paul@clubi.ie \
--cc=pelle@dsv.su.se \
--cc=trond.myklebust@fys.uio.no \
/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.