Date: Mon, 11 Dec 2000 22:09:57 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jhb@FreeBSD.ORG (John Baldwin) Cc: arch@FreeBSD.ORG Subject: Re: Can !curproc touch Message-ID: <200012112209.PAA29128@usr08.primenet.com> In-Reply-To: <XFMail.001211135320.jhb@FreeBSD.org> from "John Baldwin" at Dec 11, 2000 01:53:20 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I've got a question about p_cred in proc, specifically p_cred->pc_ucred. In
> several VOP's and other places we use p_cred->pc_ucred (aka p_ucred) as the
> credentials if we don't already have one. The problem arises if another
> process can crfree() that ucred either by a crcopy() or a direct crfree() of
> p_ucred.
I would suggest that credential instances are established
separately from their use.
Ideally, if I am logged in 5 places, I have exactly one
instance of my credentials structure lying around.
This is much more important for things like a fixed SMBFS,
which uses per-user credentials across the mount in order
to establish per user zccess controls, enforced by the
server (the current mount can not do this, since there is
no way for the kernel to query a user session about
credentials). In this case, you'd expect that a credenital
would be something like:
struct mycred {
struct mycred *nextcred;
char *nonce;
void *cred_for_nonce;
};
When one of my login instances authenticates to a particular
credential requiring system, represented by a particular
nonce, then all should be authenticated (I am authenticating
to the system, not to a session instance; consider an X
session with multiple xterm's, where each xterm does not
require seperate authentication).
What this basically means is that you need a lock, or use an
atomic operation, in order to maintain a reference count on
the credential object.
When a function enters on to dereference the credential
pointer, it acquires a reference.
The only remaining houskeeping is setting the reference count
to one when the credential is instanced, and deleting it on
the 1->0 reference transition.
A lot of the issues having to do with SMP references should
be handled this way; so should the vnode issues (e.g. when a
vnode is referenced by the directory lookup cache, the cache
should hold a reference to it; each open instance should
similarly hold a reference to it, etc.).
You aren't trying to protect if from manipulation, once it
is established (manipulation would require a light weight
lock held over the manipulation event, if it were a common
case; better to set the lock only on a multiply referenced
object (e.g., have something like a "has_alias" flag, and
if it's not set, ignore the locking, while requiring the
lock to change the flag; since the operation is atomic, and
you guarantee ordering, where the lock is held, the flag is
set, the lock is released, the lock is acquired for other
manipulation or reading now the flag is set... you are safe
to do a quick test, and unaliased operations proceed quickly).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012112209.PAA29128>