From: Peter Staubach <staubach@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfsd: permit unauthenticated stat of export root
Date: Fri, 08 Aug 2008 16:32:17 -0400 [thread overview]
Message-ID: <489CAD51.6080106@redhat.com> (raw)
In-Reply-To: <20080808202106.GR15265@fieldses.org>
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.
I will try it when I can, but I was thinking of just watching
the traffic generated during the mount. It shouldn't matter
whether the mount is done with krb5 or not, the sequence of
NFS operations should be the same.
Thanx...
ps
next prev parent reply other threads:[~2008-08-08 20:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-07 18:11 [PATCH] nfsd: permit unauthenticated stat of export root J. Bruce Fields
2008-08-07 18:23 ` Peter Staubach
2008-08-07 19:16 ` J. Bruce Fields
2008-08-07 19:39 ` Peter Staubach
2008-08-07 20:41 ` J. Bruce Fields
2008-08-08 20:21 ` J. Bruce Fields
2008-08-08 20:32 ` Peter Staubach [this message]
2008-08-08 20:39 ` J. Bruce Fields
2008-08-11 20:51 ` Peter Staubach
2008-08-11 21:26 ` J. Bruce Fields
2008-08-11 21:29 ` Peter Staubach
2008-08-11 22:11 ` J. Bruce Fields
2008-08-11 21:27 ` Peter Staubach
2008-08-11 21:38 ` Trond Myklebust
2008-08-12 15:43 ` J. Bruce Fields
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=489CAD51.6080106@redhat.com \
--to=staubach@redhat.com \
--cc=bfields@fieldses.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox