Re: [PATCH] RFC: export options for junctions

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

 



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@xxxxxxxxxx>
>> ---
>> 
>> 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@xxxxxxxxxxxxxxx
> 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@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