Re: [PATCH] nfsd: permit unauthenticated stat of export root

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



J. Bruce Fields wrote:
On Thu, Aug 07, 2008 at 04:41:54PM -0400, J. Bruce Fields wrote:
On Thu, Aug 07, 2008 at 03:39:45PM -0400, Peter Staubach wrote:
J. Bruce Fields wrote:
On Thu, Aug 07, 2008 at 02:23:40PM -0400, Peter Staubach wrote:
I would think that you might want to have nfsd3_proc_getattr()
in this list too.  Some clients may need to generate a GETATTR
if they need the attributes for the root node.
Do you know of any? rfc 2623 makes it sound like those clients are out
of luck.  And testing confirms that this patch is sufficient for the
linux client, at least.
I believe that the Solaris client may.  I think that it may
use the attributes returned from the FSINFO call, if there
are any, to prevent the additional GETATTR, but this should
be tested.  It might also be interesting to test out a
readonly failover mount on the Solaris client to see what
behavior that that exhibits.
OK, could be.  Volunteers to test that welcomed--for now I think I'll
stick to the list in the RFC.

By the way, I don't mean to brush off the idea, it's just that this
satisfies my immediate problem, and it would be extremely easy for
someone else to test:

	- Apply this patch to a linux nfs server, export a filesystem with
		/export	*(sec=krb5)
	- mount -osec=krb5 server:/export from a solaris client.
	- report whether it works, and get a packet capture if not.

... If someone gets a chance to figure out the Solaris client behavior,
that'd be great.

The Solaris client behaves plus or minus like the Linux client.
It generates a GETATTR unless it receives the attributes via
one of the previous calls.  In the Solaris case, it is an FSINFO
call.

The current Linux NFS server does not return attributes for the
PATHCONF, FSINFO, or FSSTAT calls.

Unless these calls are modified, then the NFSv3 GETATTR will need
to be allowed for the same reason that the NFSv2 GETATTR is
allowed.  The NFS client needs, at the very least, the file type
of the node that it is mounting.

I am confused as to how the testing could have been successful.

   Thanx...

      ps
--
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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux