On Sat, Jun 30, 2001 at 08:19:35PM -0400, Greg A. Woods wrote:
> [ On Thursday, June 28, 2001 at 19:19:49 (+0200), Manuel Bouyer wrote: ]    
> > Subject: Re: very weird NFS/VND error during "make depend" of kernel....   
> > 
> > I think this is the same thing: you have to check something when               
> > a client comes it anyway (it may be allowed to access one mount point          
> > but not one other).                                                            
> 
> Indeed -- but if some state is maintained on the server side (state
> that's got to be there anyway for showmount to work, IIUC) then that
> would seem to be the best choice for such an authorisation check.
> 
> > I actually like to be able to deny access to a client on the fly, without      
> > need to umount the filesystem on the client.                                   
> 
> I agree that being able to forcibly deny access to a client with an
> existing mount is an important feature.
> 
> However the current "implementation" is enirely the wrong way to go
> about authorisation.  What ends up happening is that suddenly individual
> file accesses on the client side get strange errors, such as EIO of all
> things!  (and EPERM only for new open() attempts)  This is not right.
> (and it's very very annoying if you're running busy clients, such as
> with 'make build's too!)

The current isn't completely wrong. It's just that we need to stop the
nfsd server while mountd is working (and this is what I do by hand to avoid
this when I change the export list on the server:
/etc/rc.d/nfsd stop
/etc/rc.d/mountd reload
showmount -e
/etc/rc.d/nfsd start)
About the EIO instead of something more sensible, it's possible that the
problem is on the client side, but I don't know NFS well enouth to
tell for sure.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--