On Wed, May 14, 2003 at 11:43:31AM +0100, David Howells wrote:
> Here's a revised patch for adding PAG support that incorporates suggestions
> and corrections I've been sent.
Please don't call this a pag. PAGs are defined as a simple unique
integer session identifier [1]. Their main purpose it to provide a
isolated permission environment, think of it as a chroot. So joining
or leaving a PAG is just plain wrong.
The implementation to add a PAG to Linux is really nothing more than
adding single integer to the task and file structs. And a couple of
functions to set a new unique value and query the value.
AFS (and possibly DFS) style token management uses both the user id
(fsuid?) and PAG id. It has simple rules,
All processes with (pag == 0 and same uid) share the same tokens.
All processes with pag != 0 share the same tokens.
So this really works a lot like chroot. Normally everyone who logs in
inherits pag 0 from the init task and permissions will be shared based
on the userid. However if login newpags' us into a isolated environment
permissions are based on this session.
But the presented code seems to mix up sessions, tokens, lifetimes,
permissions. I cannot provide a isolated environment because people can
both join and leave an existing pag. The in-kernel token cache seems to
be more important, but things like tokens that expire and have to be
replaced while a file is already open are not dealt with.
This was my last mail on the subject as I seem the be the only one on
that actually seem to view PAGs the way I do.
Jan
[1] Integrating Security in a Large Distributed System (# 12)
Satyanarayanan, M.
ACM Transactions on Computer Systems
Aug. 1989, Vol. 7, No. 3, pp. 247-280
http://www-2.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/sec89.pdf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:53 EST