[PATCH 2/9] mount.nfs: Don't allow the user to specify addr= or clientaddr=.

[PATCH 2/9] mount.nfs: Don't allow the user to specify addr= or clientaddr=.

[Chuck Lever]

The current mount.nfs implementation doesn't allow users to specify their
own addr= or clientaddr= option.  The new string-based interface does
allow this, even though nfs(5) does not document 'addr=' and specifically
forbids adding 'clientaddr='.

Make the addition of either option by the user a permanent error.

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

 utils/mount/stropts.c |   32 ++++++++++++++++++++++++--------
 1 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index ca79ce0..e43bbf4 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -130,7 +130,7 @@ static int get_my_ipv4addr(char *ip_addr, int len)
 
 /*
  * Walk through our mount options string, and indicate the presence
- * of 'bg', 'retry=', and 'clientaddr='.
+ * of 'bg', 'retry=', 'addr=', and 'clientaddr='.
  */
 static void extract_interesting_options(char *opts)
 {
@@ -161,9 +161,10 @@ static void extract_interesting_options(char *opts)
 }
 
 /*
- * Append the "addr=" option to the options string.
+ * Append the 'addr=' option to the options string.
  *
- * We always add our own addr= to the end of the options string.
+ * Returns 1 if 'addr=' option created successfully;
+ * otherwise zero.
  */
 static int append_addr_opt(const char *spec, char **extra_opts)
 {
@@ -206,9 +207,9 @@ static int append_addr_opt(const char *spec, char **extra_opts)
 }
 
 /*
- * Append the "clientaddr=" option to the options string.
+ * Append the 'clientaddr=' option to the options string.
  *
- * Returns 1 if clientaddr option created successfully;
+ * Returns 1 if 'clientaddr=' option created successfully;
  * otherwise zero.
  */
 static int append_clientaddr_opt(const char *spec, char **extra_opts)
@@ -257,7 +258,12 @@ int nfsmount_s(const char *spec, const char *node, int flags,
 
 	extract_interesting_options(*extra_opts);
 
-	if (!addr_opt && !append_addr_opt(spec, extra_opts))
+	if (!bg && addr_opt) {
+		nfs_error(_("%s: Illegal option: 'addr='"), progname);
+		goto fail;
+	}
+
+	if (!append_addr_opt(spec, extra_opts))
 		goto fail;
 
 	if (verbose)
@@ -299,10 +305,20 @@ int nfs4mount_s(const char *spec, const char *node, int flags,
 
 	extract_interesting_options(*extra_opts);
 
-	if (!addr_opt && !append_addr_opt(spec, extra_opts))
+	if (addr_opt) {
+		nfs_error(_("%s: Illegal option: 'addr='"), progname);
+		goto fail;
+	}
+
+	if (ca_opt) {
+		nfs_error(_("%s: Illegal option: 'clientaddr='"), progname);
+		goto fail;
+	}
+
+	if (!append_addr_opt(spec, extra_opts))
 		goto fail;
 
-	if (!ca_opt && !append_clientaddr_opt(spec, extra_opts))
+	if (!append_clientaddr_opt(spec, extra_opts))
 		goto fail;
 
 	if (verbose)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH 2/9] mount.nfs: Don't allow the user to specify addr= or clientaddr=.

[J. Bruce Fields]

On Fri, Aug 24, 2007 at 01:11:16PM -0400, Chuck Lever wrote:
> The current mount.nfs implementation doesn't allow users to specify their
> own addr= or clientaddr= option.

Don't we need clientaddr= in some cases to get the callback channel
working?

> The new string-based interface does allow this, even though nfs(5)
> does not document 'addr=' and specifically forbids adding
> 'clientaddr='.

It says that it's currently ignored, which isn't the same as forbidding
it.

I'm probably missing the point of the patch.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH 2/9] mount.nfs: Don't allow the user to specify addr= or clientaddr=.

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

J. Bruce Fields wrote:
> On Fri, Aug 24, 2007 at 01:11:16PM -0400, Chuck Lever wrote:
>> The current mount.nfs implementation doesn't allow users to specify their
>> own addr= or clientaddr= option.
> 
> Don't we need clientaddr= in some cases to get the callback channel
> working?

The mount.nfs command adds a clientaddr option of its own before doing 
the syscall.  The point of the patch is to prevent passing in a 
user-created clientaddr=.

Does anyone know of a use case where an exposed clientaddr= is needed?

>> The new string-based interface does allow this, even though nfs(5)
>> does not document 'addr=' and specifically forbids adding
>> 'clientaddr='.
> 
> It says that it's currently ignored, which isn't the same as forbidding
> it.

nfs(5) is likely incorrect.  It's arguable what "currently ignored" 
means -- it probably means the mount command ignores it, if specified, 
and uses its own address anyway.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH 2/9] mount.nfs: Don't allow the user to specify addr= or clientaddr=.

[Jeff Layton]

On Fri, 24 Aug 2007 14:16:40 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:

> J. Bruce Fields wrote:
> > On Fri, Aug 24, 2007 at 01:11:16PM -0400, Chuck Lever wrote:
> >> The current mount.nfs implementation doesn't allow users to specify their
> >> own addr= or clientaddr= option.
> > 
> > Don't we need clientaddr= in some cases to get the callback channel
> > working?
> 
> The mount.nfs command adds a clientaddr option of its own before doing 
> the syscall.  The point of the patch is to prevent passing in a 
> user-created clientaddr=.
> 
> Does anyone know of a use case where an exposed clientaddr= is needed?
> 

Mounting through a NAT router. The callback address that mount.nfs adds
might not be reachable by the server, so the user will need to specify
it.

> >> The new string-based interface does allow this, even though nfs(5)
> >> does not document 'addr=' and specifically forbids adding
> >> 'clientaddr='.
> > 
> > It says that it's currently ignored, which isn't the same as forbidding
> > it.
> 
> nfs(5) is likely incorrect.  It's arguable what "currently ignored" 
> means -- it probably means the mount command ignores it, if specified, 
> and uses its own address anyway.
> 

mount.nfs should definitely pass this info to the kernel (if it doesn't
already).

-- 
Jeff Layton <jlayton@redhat.com>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs