Re: mount.nfs: access denied by server

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Aug 21, 2009 at 05:08:12PM -0400, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 16:59 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 21, 2009 at 04:39:53PM -0400, Peter Staubach wrote:
> > > Tom Haynes wrote:
> > > > J. Bruce Fields wrote:
> > > >>
> > > >>> Right now, we use AUTH_SYS if the mount command didn't specify a
> > > >>> flavor, but the flavor we're going to use is always checked against
> > > >>> the server's returned list.  You seem to be suggesting we should
> > > >>> ignore the server's list entirely if sec= was specified...?
> > > >>>     
> > > >>
> > > >> Yes.  I can't see what practical problems that would cause.
> > > >>
> > > 
> > > Here, I am going to disagree.  The client should compare the
> > > flavor specified with the list of authentication flavors
> > > returned by the server and if the specific flavor isn't on
> > > the list, then the mount attempt should be failed.
> > 
> > Why?  What can go wrong if you just try the flavor?
> > 
> > Ugh: to answer my own question: ok, if the server allows auth_sys for
> > the NFS operations required on mount (as suggested by the security
> > considerations rfc), then that would mean mount would always succeed,
> > and nobody would see the error until the first operation on the
> > filesystem.  It would be better to return the error on mount.
> > 
> > So, I think I have to give in and agree with you.  People will just have
> > to upgrade their mountd's....
> 
> People have lived with the current situation for years without any
> trouble. It was only the addition of the security negotiation that
> exposed the mountd bug.
> 
> My position is that if mountd returns a clearly invalid (i.e. empty)
> list, then that's not a reason to interrupt the mount. We should just
> fall back to what we did prior to including security negotiation.

Yeah, so instead of taking my original pseudocode (which just allowed
sec= to always override even a non-empty list from the server), more
reasonable might be just to treat the empty-list case specially.

For example, maybe:

	- If the returned list is nonempty:
		- Do whatever the latest code does: probably return an
		  error if there's a clash with the sec= mount option,
		  otherwise attempt the first on the list.
	- Otherwise, if the returned list is empty:
		- Use any sec= option if provide, or auth_sys if not.

--b.