Skip to contentSkip to conversation

knfsd : export : Fix bug of svc_export_parse()

PATCH In review Wei Yongjun 2 participants 4 messages Mar 20, 2007 – Mar 27, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 knfsd : export : Fix bug of svc_export_parse()

When I export /dev/null as root, and mount it from client, mount ntf4 command will frozen.

You can test it by following command:
#exportfs -i -o fsid=0,no_root_squash,insecure,rw,async *:/dev/null #mount -t nfs4 127.0.0.1:/ /tmp

This is because in svc_export_parse() function, if check_export return false, after we reject the file handle, we must do cleanup the cache, which is not a format error of file handle.

nfsd/export.c renamed from nfsd/export.c.orig +4 -3
@@ -543,12 +543,13 @@ static int svc_export_parse(struct cache
 		if (err) goto out;
 		exp.ex_fsid = an_int;
 
-		err = check_export(nd.dentry->d_inode, exp.ex_flags);
-		if (err) goto out;
-
 		err = fsloc_parse(&mesg, buf, &exp.ex_fslocs);
 		if (err)
 			goto out;
+
+		err = check_export(nd.dentry->d_inode, exp.ex_flags);
+		if (err)
+			set_bit(CACHE_NEGATIVE, &exp.h.flags);
 	}
 
 	expp = svc_export_lookup(&exp);

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

#1 lore raw

Nobody replied yet, but I think this is really a BUG of exportfs. exportfs command does not check so strictly, so maybe some unreasonable fh.key can be add to /proc/net/rpc/nfsd.fh/channel, but used this key to find fh.handle, this always be fail and still retry.

It's this correct?

Quoted 22 lines

When I export /dev/null as root, and mount it from client, mount ntf4 command will frozen.

You can test it by following command:
#exportfs -i -o fsid=0,no_root_squash,insecure,rw,async *:/dev/null #mount -t nfs4 127.0.0.1:/ /tmp

This is because in svc_export_parse() function, if check_export return false, after we reject the file handle, we must do cleanup the cache, which is not a format error of file handle.

nfsd/export.c renamed from nfsd/export.c.orig +0 -3
@@ -543,12 +543,13 @@ static int svc_export_parse(struct cache
 		if (err) goto out;
 		exp.ex_fsid = an_int;
 
-		err = check_export(nd.dentry->d_inode, exp.ex_flags);
-		if (err) goto out;
-

nfsd/export.c static int svc_export_parse(struct cache · line 555

Quoted 10 lines
nfsd/export.c renamed from nfsd/export.c.orig +4 -0
 		err = fsloc_parse(&mesg, buf, &exp.ex_fslocs);
 		if (err)
 			goto out;
+
+		err = check_export(nd.dentry->d_inode, exp.ex_flags);
+		if (err)
+			set_bit(CACHE_NEGATIVE, &exp.h.flags);
 	}
 
 	expp = svc_export_lookup(&exp);

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

#2 lore raw
Quoted 6 lines · On Tuesday March 27, [email protected] wrote:

Nobody replied yet, but I think this is really a BUG of exportfs. exportfs command does not check so strictly, so maybe some unreasonable fh.key can be add to /proc/net/rpc/nfsd.fh/channel, but used this key to find fh.handle, this always be fail and still retry.

It's this correct?

Sorry for not replying earlier.

Yes, you have identified a real problem, but I'm not sure I agree with the first.

If someone (mountd) tried to tell the kernel to export "/dev/null", it fails with an error (-ENODIR), and I think this is correct.

Mountd should respond properly to this error, which it doesn't at the moment.
When the request comes via the MOUNT protocol from an NFSv2 or NFSv3 client, mountd will fail the mount as it should.
However when the request comes from the kernel due to an NFSv4 request, the error is just ignored. In that case we really should be telling the kernel that the filehandle is not valid by writing out an appropriate message.

Maybe something like this in nfs-utils.
What do you think?

### Diffstat output

 ./utils/mountd/cache.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
utils/mountd/cache.c +6 -3
diff .prev/utils/mountd/cache.c ./utils/mountd/cache.c
@@ -469,7 +469,8 @@ void nfsd_fh(FILE *f)
 	}
 
 	if (found)
-		cache_export_ent(dom, found, found_path);
+		if (cache_export_ent(dom, found, found_path) < 0)
+			found = 0;
 
 	qword_print(f, dom);
 	qword_printint(f, fsidtype);
@@ -619,8 +620,10 @@ void nfsd_export(FILE *f)
 	}
 
 	if (found) {
-		dump_to_cache(f, dom, path, &found->m_export);
-		mountlist_add(dom, path);
+		if (dump_to_cache(f, dom, path, &found->m_export) < 0)
+			dump_to_cache(f, dom, path, NULL);
+		else
+			mountlist_add(dom, path);
 	} else {
 		dump_to_cache(f, dom, path, NULL);
 	}

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

#3 lore raw

I have test some of the export entry's type: file, dir, symlink,
block device, char device, socket , fifo, and dir which is a mount entry used your patch, this patch can resolve all of this problem.
Thanks

Quoted 54 lines · Neil Brown
Quoted 7 lines · On Tuesday March 27, [email protected] wrote:

Nobody replied yet, but I think this is really a BUG of exportfs. exportfs command does not check so strictly, so maybe some unreasonable fh.key can be add to /proc/net/rpc/nfsd.fh/channel, but used this key to find fh.handle, this always be fail and still retry.

It's this correct?

Sorry for not replying earlier.

Yes, you have identified a real problem, but I'm not sure I agree with the first.

If someone (mountd) tried to tell the kernel to export "/dev/null", it fails with an error (-ENODIR), and I think this is correct.

Mountd should respond properly to this error, which it doesn't at the moment.
When the request comes via the MOUNT protocol from an NFSv2 or NFSv3 client, mountd will fail the mount as it should.
However when the request comes from the kernel due to an NFSv4 request, the error is just ignored. In that case we really should be telling the kernel that the filehandle is not valid by writing out an appropriate message.

Maybe something like this in nfs-utils.
What do you think?

### Diffstat output

 ./utils/mountd/cache.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff .prev/utils/mountd/cache.c ./utils/mountd/cache.c

utils/mountd/cache.c +2 -1
@@ -469,7 +469,8 @@ void nfsd_fh(FILE *f)
 	}
 
 	if (found)
-		cache_export_ent(dom, found, found_path);
+		if (cache_export_ent(dom, found, found_path) < 0)
+			found = 0;
 
 	qword_print(f, dom);
 	qword_printint(f, fsidtype);
@@ -619,8 +620,10 @@ void nfsd_export(FILE *f)
 	}
 

utils/mountd/cache.c void nfsd_export(FILE *f) · line 629

Quoted 10 lines
utils/mountd/cache.c +4 -2
 	if (found) {
-		dump_to_cache(f, dom, path, &found->m_export);
-		mountlist_add(dom, path);
+		if (dump_to_cache(f, dom, path, &found->m_export) < 0)
+			dump_to_cache(f, dom, path, NULL);
+		else
+			mountlist_add(dom, path);
 	} else {
 		dump_to_cache(f, dom, path, NULL);
 	}

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs