* [PATCH] RFC: export options for junctions @ 2012-03-02 19:54 Chuck Lever 2012-03-20 16:06 ` Chuck Lever 2012-03-20 19:56 ` J. Bruce Fields 0 siblings, 2 replies; 11+ messages in thread From: Chuck Lever @ 2012-03-02 19:54 UTC (permalink / raw) To: bfields; +Cc: linux-nfs 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", ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-02 19:54 [PATCH] RFC: export options for junctions Chuck Lever @ 2012-03-20 16:06 ` Chuck Lever 2012-03-20 19:56 ` J. Bruce Fields 1 sibling, 0 replies; 11+ messages in thread From: Chuck Lever @ 2012-03-20 16:06 UTC (permalink / raw) To: J. Bruce Fields, Steve Dickson; +Cc: linux-nfs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-02 19:54 [PATCH] RFC: export options for junctions Chuck Lever 2012-03-20 16:06 ` Chuck Lever @ 2012-03-20 19:56 ` J. Bruce Fields 2012-03-21 21:11 ` Chuck Lever 1 sibling, 1 reply; 11+ messages in thread From: J. Bruce Fields @ 2012-03-20 19:56 UTC (permalink / raw) To: Chuck Lever; +Cc: bfields, linux-nfs 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", > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-20 19:56 ` J. Bruce Fields @ 2012-03-21 21:11 ` Chuck Lever 2012-03-21 21:29 ` J. Bruce Fields 0 siblings, 1 reply; 11+ messages in thread From: Chuck Lever @ 2012-03-21 21:11 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Linux NFS Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-21 21:11 ` Chuck Lever @ 2012-03-21 21:29 ` J. Bruce Fields 2012-03-21 21:35 ` Chuck Lever 0 siblings, 1 reply; 11+ messages in thread From: J. Bruce Fields @ 2012-03-21 21:29 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing List 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 > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-21 21:29 ` J. Bruce Fields @ 2012-03-21 21:35 ` Chuck Lever 2012-03-22 10:59 ` J. Bruce Fields 0 siblings, 1 reply; 11+ messages in thread From: Chuck Lever @ 2012-03-21 21:35 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Linux NFS Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-21 21:35 ` Chuck Lever @ 2012-03-22 10:59 ` J. Bruce Fields 2012-03-22 19:28 ` Chuck Lever 0 siblings, 1 reply; 11+ messages in thread From: J. Bruce Fields @ 2012-03-22 10:59 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing List 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 > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-22 10:59 ` J. Bruce Fields @ 2012-03-22 19:28 ` Chuck Lever 2012-03-22 19:34 ` Chuck Lever 0 siblings, 1 reply; 11+ messages in thread From: Chuck Lever @ 2012-03-22 19:28 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Linux NFS Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-22 19:28 ` Chuck Lever @ 2012-03-22 19:34 ` Chuck Lever 2012-04-11 21:31 ` J. Bruce Fields 0 siblings, 1 reply; 11+ messages in thread From: Chuck Lever @ 2012-03-22 19:34 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Linux NFS Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-03-22 19:34 ` Chuck Lever @ 2012-04-11 21:31 ` J. Bruce Fields 2012-04-11 21:32 ` Chuck Lever 0 siblings, 1 reply; 11+ messages in thread From: J. Bruce Fields @ 2012-04-11 21:31 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing List 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 > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RFC: export options for junctions 2012-04-11 21:31 ` J. Bruce Fields @ 2012-04-11 21:32 ` Chuck Lever 0 siblings, 0 replies; 11+ messages in thread From: Chuck Lever @ 2012-04-11 21:32 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Linux NFS Mailing List 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-04-11 22:50 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-02 19:54 [PATCH] RFC: export options for junctions Chuck Lever 2012-03-20 16:06 ` Chuck Lever 2012-03-20 19:56 ` J. Bruce Fields 2012-03-21 21:11 ` Chuck Lever 2012-03-21 21:29 ` J. Bruce Fields 2012-03-21 21:35 ` Chuck Lever 2012-03-22 10:59 ` J. Bruce Fields 2012-03-22 19:28 ` Chuck Lever 2012-03-22 19:34 ` Chuck Lever 2012-04-11 21:31 ` J. Bruce Fields 2012-04-11 21:32 ` Chuck Lever
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).