Bug 27896

Summary: Error in /etc/exports invalidates entire line, not just single host.
Product: Base System Reporter: sbotsford <sbotsford>
Component: confAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description sbotsford 2001-06-05 23:40:01 UTC
if a host is defined as part of a netgroup, and is mentioned explicitly
for another line for the same file system, but with different privledges,
then the entire line is invalidated.


1.  Write lines with a single entry per client entity (host or netgroup)

0.  If a host causes a problem in a line, then it should affect that
host not the whole line:  E.g:

/nfs/home/	-maproot=root 	foo bar

should be equivalent in behaviour to 

/nfs/home/	-maproot=root	foo
/nfs/home/	-maproot=root	bar

1.  Flag for mountd to test the validity of exports file.
E.g. mountd -v /nfs/home foo.bar.com
	Mount suceeds with privleges root=nobody -- line 27
     mound -v /nfs/home explorer.bar.com
	Mount fails -- host is twice referenced line 26 and 40.

2.  Have a mountd flag so that if a host is doubly referenced, it
gets the more restrictive set of privleges, OR it gets the first set
of privleges. (along with a log message.) OR if a host is mentioned 
explicity and is in a netgroup, then then explicit reference takes
How-To-Repeat: Consider:
lindesk is the netgroup containing  dumpling, croisant, and biscuit.
linserve is the netgroup containing smaug, balrog, and gollum
explorer is a linux desktop box used for administration.

Rhea has the following exports file:
/nfs/home	-maproot=nobody lindesk 
/nfs/home	-maproot=root explorer linserve

This works.
Now add explorer to the lindesk group.
Foof! linserve can no longer mount /nfs/home.  This is counter intuitive.
especially, as writting the above line as two lines would
localize the problem to explorer.
Comment 1 Harrison Grundy 2007-03-22 04:18:51 UTC
Because given export lines can be mutually exclusive, there is no way to 
rationally handle this behavior. Throwing an error on the NFS server 
seems like the only real way to handle this.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2007-04-25 23:09:15 UTC
State Changed
From-To: open->analyzed

email feedback indicates that there should probably be an error recovery 
for this.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:50:44 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

- Set Status to "Open"