[ 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!)

Instead There should be something with the function of "force such-and-
such client to unmount such-and-such (or all) resource(s)" just like the
RFS 'fumount' command.

Now in RFS the 'fumount' function is implemented by sending a special
command to a special little (per-mount IIRC) daemon that sits waiting on
the client for just this (and a very few other) purposes.  Some people
have claimed that this scheme makes RFS unscalable, though I don't see
how this is any different than the similar scaling issues in NFS.

For NFS what I think you really want the server to do is return a
special error code for "invalid mount" when a client is forced to
unmount.  ESTALE doens't seem quite right for this, especially not for
new open() requests, etc., so maybe a new one could be invented, or an
old one that "sounds" right, like ECONNRESET or ENOTCONN, could be
"reused".  This error should probably have special meaning to the client
kernel (or at least be taken note of) so that it could mark the whole
mount as "bad" and make it harder for processes on the client, and
indeed users, to get confused about being able to access things "within"
an apparently valid exising NFS mounted filesystem.  Meanwhile the
nfsd(s) on the server should be keeping track of already authorised
clients, and then mountd would be the sole path for a client to be
authorised for a given mount.

Now I'm not an NFS protocol expert (I could probably implement something
like RFS given the spec and docs I've got, but I've avoided learning too
much about NFS guts), so I don't know if what I'm suggesting is possible
within the current specs.

However if I'm not too far off track of what's possible within the
existing protocol spec then I think if this was done carefully then
there'd be no reason to have the server kernel know anything about which
filesystems and/or directories are exported -- all control would be in
user-land via mountd and the nfsd's.  The client would ask mountd for a
mount (that's how it works now, right?), then when it first accesses
anything the nfsd would verify it's authorisation with mountd.  Once
confirmed the nfsd(s) would only check their pre-authorised client list.
A change in /etc/exports wouldn't affect any existing mounts, but a
client could be cut off by sending a special message to the nfsd(s) that
would cause the the client's authorisation for a given mount to be
invalidated and existing handles could be returned as ESTALE or
whatever.  This should avoid the window of vlunerability during a mountd
reload or restart, while at the same time giving the server admin the
ability to cut off a client with an existing mount.

If this is beyond NFSv2 and/or NFSv3 Maybe this will be the way the new
NFS V4 implementation works?  ;-)

If what I've proposed isn't possible within the spec. then in the mean
time I'm beginning to think it might be possible for mountd to figure
out for itself what export directories are on what filesystems and to
use getfsstat(2)/statfs(2) to learn what mounted filesystems have
exports and then to be more careful about deleting old entries (i.e.
instead of just wacking them all out as it does now).  I.e. just be more
careful and explicit in implementing the add/delete algorithm originally
attempted by Bill Sommerfeld.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>