Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 06 Jul 1997 18:23:32 +0200
From:      Sebastian Lederer <lederer@bonn-online.com>
To:        Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: NFS locking, was: Re: NFS V3 is it stable?
Message-ID:  <33BFC684.167EB0E7@bonn-online.com>
References:  <199707041537.LAA19945@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul wrote:

> I can tell you at least one thing nfssys() does: if you look at the
> keylogin(1) and chkey(1) source code from the tirpcsrc-2.3
> distribution (on playground.sun.com:/pub/rpc, among other places),
> you'll see that it's used for revoking Secure RPC credentials for use
> with 'Secure NFS' (nfssys(NFS_REVAUTH, &foo)). What I don't know is
> how Secure RPC credentials are established for secure NFS in the
> first place. I think the kernel may actually communicate with the
> keyserv daemon to do it, but I'm not certain.

Assuming that nfssys() is the same as nfssvc() in BSD,
nfssys() is mainly used for starting the nfs server kernel
thread or the nfs read ahead daemon.
In BSD, nfssvc() it is also used to do kerberos authentication for nfs.
This would be similar to Secure RPC authentication in Solaris.


> Here's how it works (I think):
> 
> - A process on a client decides it wants to lock something so it uses
>   the flock() or fcntl() system calls.
> - The kernel eventually works out that the filesystem on which the
>   process is trying to establish the lock is an NFS filesystem.
> - The kernel uses the klm_prot (llockmgr) protocol to ask the
>   local rpc.lockd to go out and talk to the rpc.lockd on the NFS
>   server and ask it for a lock.
> - The rpc.lockd on the server gets the request, locks the file, then
>   replies back to the client.
> - The rpc.lockd on the client gets the remote lockd's reply and replies
>   back to the kernel to tell it what happened.
>

That's exactly the way I think it works.

Perhaps it would be easier to implement a pseudo-device 
like /dev/klog or /dev/tun to communicate with the local rpc.lockd
rather than a full-fledged rpc protocol. Well, that might be
not as elegant...

Of course, the most elegant solution would be to place the
complete rpc.lockd inside a kernel process. I could be of little help,
then, since I've never did kernel programming before. I would still
try to do what I can, though, as I think nfs locking is quite
important (nearly all the competition OS's have it, by now).

Best regards,
Sebastian Lederer


-- 
Sebastian Lederer
lederer@bonn-online.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33BFC684.167EB0E7>