[PATCH] RFC: export options for junctions

[PATCH] RFC: export options for junctions

[Chuck Lever]

At Connectathon, I ran my FedFS-enabled client in a guest environment
with NAT networking.  This made the source port for my NFS connections
unprivileged.

Attempting to access a junction on my test server failed with a
"client insecure" error on the server, even if I specified the
"insecure" export option on the parent export.  I added "insecure" to
the default junction export options, and this fixed the problem.

Bruce suggested, however, that the correct way to address this is to
have junctions inherit the export options of their parent.  I don't
see a direct way to do this, so I'm posting this patch as a
conversation starter.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---

 utils/mountd/cache.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
index ac9cdbd..35bc2e9 100644
--- a/utils/mountd/cache.c
+++ b/utils/mountd/cache.c
@@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
 			ptr += len;
 		} else {
 			if (last_path == NULL)
-				len = snprintf(ptr, remaining, "refer=%s@%s",
+				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
 							rootpath, server);
 			else
 				len = snprintf(ptr, remaining, ":%s@%s",

Re: [PATCH] RFC: export options for junctions

[Chuck Lever]

Bump.

Any ideas?  Bueller?  Anyone?


On Mar 2, 2012, at 2:54 PM, Chuck Lever wrote:

> At Connectathon, I ran my FedFS-enabled client in a guest environment
> with NAT networking.  This made the source port for my NFS connections
> unprivileged.
> 
> Attempting to access a junction on my test server failed with a
> "client insecure" error on the server, even if I specified the
> "insecure" export option on the parent export.  I added "insecure" to
> the default junction export options, and this fixed the problem.
> 
> Bruce suggested, however, that the correct way to address this is to
> have junctions inherit the export options of their parent.  I don't
> see a direct way to do this, so I'm posting this patch as a
> conversation starter.
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
> utils/mountd/cache.c |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> index ac9cdbd..35bc2e9 100644
> --- a/utils/mountd/cache.c
> +++ b/utils/mountd/cache.c
> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
> 			ptr += len;
> 		} else {
> 			if (last_path == NULL)
> -				len = snprintf(ptr, remaining, "refer=%s@%s",
> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
> 							rootpath, server);
> 			else
> 				len = snprintf(ptr, remaining, ":%s@%s",
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] RFC: export options for junctions

[J. Bruce Fields]

On Fri, Mar 02, 2012 at 02:54:51PM -0500, Chuck Lever wrote:
> At Connectathon, I ran my FedFS-enabled client in a guest environment
> with NAT networking.  This made the source port for my NFS connections
> unprivileged.
> 
> Attempting to access a junction on my test server failed with a
> "client insecure" error on the server, even if I specified the
> "insecure" export option on the parent export.  I added "insecure" to
> the default junction export options, and this fixed the problem.
> 
> Bruce suggested, however, that the correct way to address this is to
> have junctions inherit the export options of their parent.  I don't
> see a direct way to do this, so I'm posting this patch as a
> conversation starter.

I think you want to do something like the search in
nfs-utils/utils/mountd/cache.c:lookup_export()--look for the export with
the longest matching path, and copy options from that.

--b.

> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
>  utils/mountd/cache.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> index ac9cdbd..35bc2e9 100644
> --- a/utils/mountd/cache.c
> +++ b/utils/mountd/cache.c
> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
>  			ptr += len;
>  		} else {
>  			if (last_path == NULL)
> -				len = snprintf(ptr, remaining, "refer=%s@%s",
> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
>  							rootpath, server);
>  			else
>  				len = snprintf(ptr, remaining, ":%s@%s",
> 

Re: [PATCH] RFC: export options for junctions

[Chuck Lever]

Hi-

On Mar 20, 2012, at 3:56 PM, J. Bruce Fields wrote:

> On Fri, Mar 02, 2012 at 02:54:51PM -0500, Chuck Lever wrote:
>> At Connectathon, I ran my FedFS-enabled client in a guest environment
>> with NAT networking.  This made the source port for my NFS connections
>> unprivileged.
>> 
>> Attempting to access a junction on my test server failed with a
>> "client insecure" error on the server, even if I specified the
>> "insecure" export option on the parent export.  I added "insecure" to
>> the default junction export options, and this fixed the problem.
>> 
>> Bruce suggested, however, that the correct way to address this is to
>> have junctions inherit the export options of their parent.  I don't
>> see a direct way to do this, so I'm posting this patch as a
>> conversation starter.
> 
> I think you want to do something like the search in
> nfs-utils/utils/mountd/cache.c:lookup_export()--look for the export with
> the longest matching path, and copy options from that.

This still looks hopelessly complex.

  1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.

  2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.

  3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)

  4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().

For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.

Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?

> --b.
> 
>> 
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>> 
>> utils/mountd/cache.c |    2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
>> index ac9cdbd..35bc2e9 100644
>> --- a/utils/mountd/cache.c
>> +++ b/utils/mountd/cache.c
>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
>> 			ptr += len;
>> 		} else {
>> 			if (last_path == NULL)
>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
>> 							rootpath, server);
>> 			else
>> 				len = snprintf(ptr, remaining, ":%s@%s",
>> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] RFC: export options for junctions

[J. Bruce Fields]

On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
> Hi-
> 
> On Mar 20, 2012, at 3:56 PM, J. Bruce Fields wrote:
> 
> > On Fri, Mar 02, 2012 at 02:54:51PM -0500, Chuck Lever wrote:
> >> At Connectathon, I ran my FedFS-enabled client in a guest environment
> >> with NAT networking.  This made the source port for my NFS connections
> >> unprivileged.
> >> 
> >> Attempting to access a junction on my test server failed with a
> >> "client insecure" error on the server, even if I specified the
> >> "insecure" export option on the parent export.  I added "insecure" to
> >> the default junction export options, and this fixed the problem.
> >> 
> >> Bruce suggested, however, that the correct way to address this is to
> >> have junctions inherit the export options of their parent.  I don't
> >> see a direct way to do this, so I'm posting this patch as a
> >> conversation starter.
> > 
> > I think you want to do something like the search in
> > nfs-utils/utils/mountd/cache.c:lookup_export()--look for the export with
> > the longest matching path, and copy options from that.
> 
> This still looks hopelessly complex.

I bet there's an easy way to do it if we just modify the right code.
Remind me where your nfs-utils patches live, and maybe I could take a
look?

--b.

> 
>   1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
> 
>   2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
> 
>   3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)
> 
>   4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
> 
> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
> 
> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
> 
> > --b.
> > 
> >> 
> >> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >> ---
> >> 
> >> utils/mountd/cache.c |    2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> >> index ac9cdbd..35bc2e9 100644
> >> --- a/utils/mountd/cache.c
> >> +++ b/utils/mountd/cache.c
> >> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
> >> 			ptr += len;
> >> 		} else {
> >> 			if (last_path == NULL)
> >> -				len = snprintf(ptr, remaining, "refer=%s@%s",
> >> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
> >> 							rootpath, server);
> >> 			else
> >> 				len = snprintf(ptr, remaining, ":%s@%s",
> >> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> 
> 
> 
> 

Re: [PATCH] RFC: export options for junctions

[Chuck Lever]

On Mar 21, 2012, at 5:29 PM, J. Bruce Fields wrote:

> On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
>> Hi-
>> 
>> On Mar 20, 2012, at 3:56 PM, J. Bruce Fields wrote:
>> 
>>> On Fri, Mar 02, 2012 at 02:54:51PM -0500, Chuck Lever wrote:
>>>> At Connectathon, I ran my FedFS-enabled client in a guest environment
>>>> with NAT networking.  This made the source port for my NFS connections
>>>> unprivileged.
>>>> 
>>>> Attempting to access a junction on my test server failed with a
>>>> "client insecure" error on the server, even if I specified the
>>>> "insecure" export option on the parent export.  I added "insecure" to
>>>> the default junction export options, and this fixed the problem.
>>>> 
>>>> Bruce suggested, however, that the correct way to address this is to
>>>> have junctions inherit the export options of their parent.  I don't
>>>> see a direct way to do this, so I'm posting this patch as a
>>>> conversation starter.
>>> 
>>> I think you want to do something like the search in
>>> nfs-utils/utils/mountd/cache.c:lookup_export()--look for the export with
>>> the longest matching path, and copy options from that.
>> 
>> This still looks hopelessly complex.
> 
> I bet there's an easy way to do it if we just modify the right code.
> Remind me where your nfs-utils patches live, and maybe I could take a
> look?

I admit to not being at all familiar with mountd's export cache, so I simply haven't found anything that appears to do what is needed.

Steve has already taken the basic junction support patch, so you can just grab a copy of the current nfs-utils git repo.  Junction supported was added with commit ab74900f (according to my copy of his repo).

Thanks very much for your time.

> --b.
> 
>> 
>>  1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
>> 
>>  2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
>> 
>>  3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)
>> 
>>  4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
>> 
>> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
>> 
>> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
>> 
>>> --b.
>>> 
>>>> 
>>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>>> ---
>>>> 
>>>> utils/mountd/cache.c |    2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>> 
>>>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
>>>> index ac9cdbd..35bc2e9 100644
>>>> --- a/utils/mountd/cache.c
>>>> +++ b/utils/mountd/cache.c
>>>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
>>>> 			ptr += len;
>>>> 		} else {
>>>> 			if (last_path == NULL)
>>>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
>>>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
>>>> 							rootpath, server);
>>>> 			else
>>>> 				len = snprintf(ptr, remaining, ":%s@%s",
>>>> 
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] RFC: export options for junctions

[J. Bruce Fields]

On Wed, Mar 21, 2012 at 05:35:17PM -0400, Chuck Lever wrote:
> 
> On Mar 21, 2012, at 5:29 PM, J. Bruce Fields wrote:
> 
> > On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
> >>  1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
> >> 
> >>  2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
> >> 
> >>  3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)

You should be able to skip steps 2 and 3 and use dupexportent.

Does that sound doable?

--b.

> >> 
> >>  4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
> >> 
> >> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
> >> 
> >> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
> >> 
> >>> --b.
> >>> 
> >>>> 
> >>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >>>> ---
> >>>> 
> >>>> utils/mountd/cache.c |    2 +-
> >>>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>> 
> >>>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> >>>> index ac9cdbd..35bc2e9 100644
> >>>> --- a/utils/mountd/cache.c
> >>>> +++ b/utils/mountd/cache.c
> >>>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
> >>>> 			ptr += len;
> >>>> 		} else {
> >>>> 			if (last_path == NULL)
> >>>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
> >>>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
> >>>> 							rootpath, server);
> >>>> 			else
> >>>> 				len = snprintf(ptr, remaining, ":%s@%s",
> >>>> 
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >> -- 
> >> Chuck Lever
> >> chuck[dot]lever[at]oracle[dot]com
> >> 
> >> 
> >> 
> >> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> 
> 
> 
> 

Re: [PATCH] RFC: export options for junctions

[Chuck Lever]

On Mar 22, 2012, at 6:59 AM, J. Bruce Fields wrote:

> On Wed, Mar 21, 2012 at 05:35:17PM -0400, Chuck Lever wrote:
>> 
>> On Mar 21, 2012, at 5:29 PM, J. Bruce Fields wrote:
>> 
>>> On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
>>>> 1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
>>>> 
>>>> 2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
>>>> 
>>>> 3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)
> 
> You should be able to skip steps 2 and 3 and use dupexportent.
> 
> Does that sound doable?

The current junction lookup logic uses mkexportent(), which returns a statically allocated exportent that doesn't need to be freed.  That makes the lookup_junction() call site simple, but that's too clever by half.  Using dupexportent() unchanged would require some reworking there in order to free the duplicated exportent.

Also I'm not quite sure how to safely combine the use of mkexportent(), which parses the referral options we just created, and dupexportent(), which would duplicate the options from the parent, but would walk on e_hostname.

I could address both those problems by constructing a new function which was an amalgam of the two.

I still have to play with the lookup_export() logic to see how to find a junction's parent export.

> --b.
> 
>>>> 
>>>> 4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
>>>> 
>>>> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
>>>> 
>>>> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
>>>> 
>>>>> --b.
>>>>> 
>>>>>> 
>>>>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>>>>> ---
>>>>>> 
>>>>>> utils/mountd/cache.c |    2 +-
>>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>> 
>>>>>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
>>>>>> index ac9cdbd..35bc2e9 100644
>>>>>> --- a/utils/mountd/cache.c
>>>>>> +++ b/utils/mountd/cache.c
>>>>>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
>>>>>> 			ptr += len;
>>>>>> 		} else {
>>>>>> 			if (last_path == NULL)
>>>>>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
>>>>>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
>>>>>> 							rootpath, server);
>>>>>> 			else
>>>>>> 				len = snprintf(ptr, remaining, ":%s@%s",
>>>>>> 
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> 
>>>> -- 
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>> 
>>>> 
>>>> 
>>>> 
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] RFC: export options for junctions

[Chuck Lever]

On Mar 22, 2012, at 3:28 PM, Chuck Lever wrote:

> 
> On Mar 22, 2012, at 6:59 AM, J. Bruce Fields wrote:
> 
>> On Wed, Mar 21, 2012 at 05:35:17PM -0400, Chuck Lever wrote:
>>> 
>>> On Mar 21, 2012, at 5:29 PM, J. Bruce Fields wrote:
>>> 
>>>> On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
>>>>> 1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
>>>>> 
>>>>> 2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
>>>>> 
>>>>> 3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)
>> 
>> You should be able to skip steps 2 and 3 and use dupexportent.
>> 
>> Does that sound doable?
> 
> The current junction lookup logic uses mkexportent(), which returns a statically allocated exportent that doesn't need to be freed.  That makes the lookup_junction() call site simple, but that's too clever by half.  Using dupexportent() unchanged would require some reworking there in order to free the duplicated exportent.
> 
> Also I'm not quite sure how to safely combine the use of mkexportent(), which parses the referral options we just created, and dupexportent(), which would duplicate the options from the parent, but would walk on e_hostname.
> 
> I could address both those problems by constructing a new function which was an amalgam of the two.

updateexportent() might do the trick.

> I still have to play with the lookup_export() logic to see how to find a junction's parent export.
> 
>> --b.
>> 
>>>>> 
>>>>> 4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
>>>>> 
>>>>> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
>>>>> 
>>>>> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
>>>>> 
>>>>>> --b.
>>>>>> 
>>>>>>> 
>>>>>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>>>>>> ---
>>>>>>> 
>>>>>>> utils/mountd/cache.c |    2 +-
>>>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
>>>>>>> index ac9cdbd..35bc2e9 100644
>>>>>>> --- a/utils/mountd/cache.c
>>>>>>> +++ b/utils/mountd/cache.c
>>>>>>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
>>>>>>> 			ptr += len;
>>>>>>> 		} else {
>>>>>>> 			if (last_path == NULL)
>>>>>>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
>>>>>>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
>>>>>>> 							rootpath, server);
>>>>>>> 			else
>>>>>>> 				len = snprintf(ptr, remaining, ":%s@%s",
>>>>>>> 
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> 
>>>>> -- 
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> 
>>> -- 
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>> 
>>> 
>>> 
>>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] RFC: export options for junctions

[J. Bruce Fields]

On Thu, Mar 22, 2012 at 03:34:18PM -0400, Chuck Lever wrote:
> 
> On Mar 22, 2012, at 3:28 PM, Chuck Lever wrote:
> 
> > 
> > On Mar 22, 2012, at 6:59 AM, J. Bruce Fields wrote:
> > 
> >> On Wed, Mar 21, 2012 at 05:35:17PM -0400, Chuck Lever wrote:
> >>> 
> >>> On Mar 21, 2012, at 5:29 PM, J. Bruce Fields wrote:
> >>> 
> >>>> On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
> >>>>> 1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
> >>>>> 
> >>>>> 2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
> >>>>> 
> >>>>> 3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)
> >> 
> >> You should be able to skip steps 2 and 3 and use dupexportent.
> >> 
> >> Does that sound doable?
> > 
> > The current junction lookup logic uses mkexportent(), which returns a statically allocated exportent that doesn't need to be freed.  That makes the lookup_junction() call site simple, but that's too clever by half.  Using dupexportent() unchanged would require some reworking there in order to free the duplicated exportent.
> > 
> > Also I'm not quite sure how to safely combine the use of mkexportent(), which parses the referral options we just created, and dupexportent(), which would duplicate the options from the parent, but would walk on e_hostname.
> > 
> > I could address both those problems by constructing a new function which was an amalgam of the two.
> 
> updateexportent() might do the trick.

Any luck with that?

--b.

> 
> > I still have to play with the lookup_export() logic to see how to find a junction's parent export.
> > 
> >> --b.
> >> 
> >>>>> 
> >>>>> 4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
> >>>>> 
> >>>>> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
> >>>>> 
> >>>>> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
> >>>>> 
> >>>>>> --b.
> >>>>>> 
> >>>>>>> 
> >>>>>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >>>>>>> ---
> >>>>>>> 
> >>>>>>> utils/mountd/cache.c |    2 +-
> >>>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>>>>> 
> >>>>>>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> >>>>>>> index ac9cdbd..35bc2e9 100644
> >>>>>>> --- a/utils/mountd/cache.c
> >>>>>>> +++ b/utils/mountd/cache.c
> >>>>>>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
> >>>>>>> 			ptr += len;
> >>>>>>> 		} else {
> >>>>>>> 			if (last_path == NULL)
> >>>>>>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
> >>>>>>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
> >>>>>>> 							rootpath, server);
> >>>>>>> 			else
> >>>>>>> 				len = snprintf(ptr, remaining, ":%s@%s",
> >>>>>>> 
> >>>>>> --
> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>> 
> >>>>> -- 
> >>>>> Chuck Lever
> >>>>> chuck[dot]lever[at]oracle[dot]com
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>> 
> >>> -- 
> >>> Chuck Lever
> >>> chuck[dot]lever[at]oracle[dot]com
> >>> 
> >>> 
> >>> 
> >>> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > -- 
> > Chuck Lever
> > chuck[dot]lever[at]oracle[dot]com
> > 
> > 
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> 
> 
> 
> 

Re: [PATCH] RFC: export options for junctions

[Chuck Lever]

On Apr 11, 2012, at 5:31 PM, J. Bruce Fields wrote:

> On Thu, Mar 22, 2012 at 03:34:18PM -0400, Chuck Lever wrote:
>> 
>> On Mar 22, 2012, at 3:28 PM, Chuck Lever wrote:
>> 
>>> 
>>> On Mar 22, 2012, at 6:59 AM, J. Bruce Fields wrote:
>>> 
>>>> On Wed, Mar 21, 2012 at 05:35:17PM -0400, Chuck Lever wrote:
>>>>> 
>>>>> On Mar 21, 2012, at 5:29 PM, J. Bruce Fields wrote:
>>>>> 
>>>>>> On Wed, Mar 21, 2012 at 05:11:40PM -0400, Chuck Lever wrote:
>>>>>>> 1.  We have to create a version of lookup_export() that does exactly what's needed to find the junction's parent.
>>>>>>> 
>>>>>>> 2.  Once we find the parent's exportent, we have to reverse parse the data in that exportent to get an options string, and concatenate that to the options string we're building for the junction itself.
>>>>>>> 
>>>>>>> 3.  Once we have the full options string for the junction, we use mkexportent() to convert it all back into another exportent.  (or is there a simple way to merge the exportents?)
>>>> 
>>>> You should be able to skip steps 2 and 3 and use dupexportent.
>>>> 
>>>> Does that sound doable?
>>> 
>>> The current junction lookup logic uses mkexportent(), which returns a statically allocated exportent that doesn't need to be freed.  That makes the lookup_junction() call site simple, but that's too clever by half.  Using dupexportent() unchanged would require some reworking there in order to free the duplicated exportent.
>>> 
>>> Also I'm not quite sure how to safely combine the use of mkexportent(), which parses the referral options we just created, and dupexportent(), which would duplicate the options from the parent, but would walk on e_hostname.
>>> 
>>> I could address both those problems by constructing a new function which was an amalgam of the two.
>> 
>> updateexportent() might do the trick.
> 
> Any luck with that?

I've got some higher priority work that is blocking this.  I may not get to it for a while.

> --b.
> 
>> 
>>> I still have to play with the lookup_export() logic to see how to find a junction's parent export.
>>> 
>>>> --b.
>>>> 
>>>>>>> 
>>>>>>> 4.  Then, we send the referral data to the kernel by converting that exportent back into a string with dump_to_cache().
>>>>>>> 
>>>>>>> For the time being, though a kludge, it seems easiest by far to simply stick the "insecure" option on all junctions.  I don't think this is otherwise terribly risky.
>>>>>>> 
>>>>>>> Maybe at some later point we can think of a cleaner way to approach this?  Is there a possible kernel solution for this (ie something that can be done in the kernel's export cache only for referrals)?
>>>>>>> 
>>>>>>>> --b.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>>>>>>>> ---
>>>>>>>>> 
>>>>>>>>> utils/mountd/cache.c |    2 +-
>>>>>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>> 
>>>>>>>>> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
>>>>>>>>> index ac9cdbd..35bc2e9 100644
>>>>>>>>> --- a/utils/mountd/cache.c
>>>>>>>>> +++ b/utils/mountd/cache.c
>>>>>>>>> @@ -853,7 +853,7 @@ locations_to_options(struct jp_ops *ops, nfs_fsloc_set_t locations,
>>>>>>>>> 			ptr += len;
>>>>>>>>> 		} else {
>>>>>>>>> 			if (last_path == NULL)
>>>>>>>>> -				len = snprintf(ptr, remaining, "refer=%s@%s",
>>>>>>>>> +				len = snprintf(ptr, remaining, "insecure,refer=%s@%s",
>>>>>>>>> 							rootpath, server);
>>>>>>>>> 			else
>>>>>>>>> 				len = snprintf(ptr, remaining, ":%s@%s",
>>>>>>>>> 
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>> 
>>>>>>> -- 
>>>>>>> Chuck Lever
>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> 
>>>>> -- 
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> 
>>> -- 
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>> 
>>> 
>>> 
>>> 
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com