I would very much advise against this... otherwise you could end up with a
kernel vs userspace deadlock very easily. Furthermore, my current patch
controls read access using a spinlock only - this means that stuff in
interrupt context can access keys; I think it'd be unwise to do otherwise.
I'm using 2 levels of locking, a kernel-side one and a user-side one. The goal
of the user-side one is _only_ to prevent other _user_ processes from using
the key while one process is atomically (To userspace) performing actions on
it. The user-space "lock" will just be another member in the struct that
describes the type of lock and the process and file-descriptor it is tied to. The
only truly atomic in-kernel lock (a per-key spinlock) is held just long enough
to read or modify the key.
Have you looked at the locking stuff the VFS does? It finds its way into all
sorts of nooks and crannies because it has to make sure locks are discarded
when their owner goes away - whatever "owner" means to the system.
User-space "references" to keys in my (incomplete) patch are file-descriptors,
so I need to keep track of those anyway (They control a ref-count increment).
Sys-calls that allow user-space to access keys would just spinlock the kernel
keyring, then if there is already a user-space lock owner, just put themselves
on a queue to be woken up when it becomes free. If it isn't locked, they will
just maintain their spinlock and do their modification.
The only time you need to check for the user-side lock is from user context,
it doesn't have meaning at any other time. I don't care if something inside of
the inherently privileged _kernel_ needs to read or modify a key atomically
during an interrupt, kernel code is generally carefully written enough. I'm
just worried about locking out malicious processes.
I think you don't really need locking anyway. You just have to be aware that
what you're dealing with may change under you.
I am worried about the potential security implications of a privileged daemon
working with keys while an unprivileged process fools around with them.
This leaves all decisions of policy to a PAM module and some configurable programs. (Like key-sh or something :-D)
I think that's probably a good idea... now we just have to sell Linus on it.
So far it's just been the easy part :-D
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
