Date: Tue, 23 Oct 2001 19:13:30 -0400 (EDT) From: Robert Watson <robert@fledge.watson.org> To: Alfred Perlstein <bright@mu.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs_lock.c Message-ID: <Pine.NEB.3.96L.1011023184741.40608A-100000@fledge.watson.org> In-Reply-To: <20011023164040.P15052@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Oct 2001, Alfred Perlstein wrote:
> * Robert Watson <rwatson@FreeBSD.org> [011023 14:11] wrote:
> > rwatson 2001/10/23 12:11:31 PDT
> >
> > Modified files:
> > sys/nfsclient nfs_lock.c
> > Log:
> > o Add two comments identifying problems with the current nfs_lock.c
> > implementation, so that the information doesn't get lost.
> > (1) /var/run/lock is looked up relative to the current thread's root
> > directory, but it's not clear that's desirable.
> > (2) A race condition associated with live credential modification on
> > a shared credential is present when privilege is granted for
> > the purposes of talking to /var/run/lock.
>
> I have a hackish idea that may resolve this, would it possible
> to run the NDINIT passing the struct thread for init's proc?
>
> That should avoid the chroot problem and at the same time avoid
> the temporary uid problem.
>
> Can you test this?
I'm not entirely certain this is the right solution either, as it asserts
that the namespace seen by init is the one relevant to rpc.lockd. With
few exceptions, the current "best" practice for setting up a rendezvous
between userland processes, the kernel, and a particular tend to fall into
the following categiories:
(1) A pseudo-device, where the /dev name is a property of either MAKEDEV
and rendezvous is coordinated using dev_t, or where the name is a
property of devfs and provided by the driver. This is used for a
variety of kernel-userland data-spewing, including syslog, pccard,
usb, my various audit implementations, Coda and Arla, etc.
(2) Name passed to kernel via a designated system call, and the credential
cached. This is used for the quota and extended attribute
implementations, which pass a name to the kernel, which is pushed down
via VFS to the individual file system. The file system performs
a name lookup relative to the calling process, and then caches a
reference to the vnode of the file, as well as a reference to the
credential of the calling process. Future access to the file is
performed using that credential, rather than the credential of the
process indirectly causing the read or write.
(3) Name passed to the kernel via a designated system call, and the
credential is not cached. Much like (2), except that the credential
used for read and write operations is that of the process indirectly
causing the operation. ktrace records are written in this manner,
as are accounting records.
For this type of kernel I/O, either (1) or (2) seems to be an acceptable
model. Arla's XFS kernel module effectively exports VFS via an RPC
mechanism to userland (but throw in a notion of a container vnode and
kernel name cache) for Arla, but the complexity is relatively high.
I'm personally a fan of (2), because as some access control models will
mediate individual read and write calls, using a more appropriate
credential is appropriate. I suspect over time I'll probably change
instances of (3) to (2) to address that problem. I hope to have time to
take a stab at (2) this evening for the nfs_lock code, but note there are
some complications, in the interests of avoiding races during changes of
the fifo vnode. If I do get something done tonight, I'll toss you a patch
to look at.
BTW, I'm not sure what (if any) weird effects might occur if you use
another process for a name lookup. I suspect that some of the current
assumptions about process locking might not hold, and would tend to avoid
it if only for that reason. Using another process's credential is also
concerning, since init could potentially decide to change its credential
(although ours doesn't, it's not precluded in the UNIX model).
> My apologies for getting so irritated with you the other day about
> this, in the future taking the time to guess at a possible solution
> might be better than simply complaining about it.
No problem. Right now, I'm pretty time-constrained--my primary concern
was to make sure that the problems were properly identified and documented
so that they didn't get lost before 5.0-RELEASE. In a sense, the timeline
for fixing them is less important than making sure they do get fixed.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011023184741.40608A-100000>