Hi Jan,

thanks for the analysis.

I see that there are more problems in the kernel than I expected.

On the other side, even plainly disallowing access in the cases which we can
not handle would be a definite improvement - as it would open the possibility
to use Coda on general purpose multiuser machines. As long as no more than
one user at a time accesses a given Coda file (when the file may be modified),
we seem to be fine.

On Fri, Mar 23, 2007 at 09:08:22PM -0400, Jan Harkes wrote:
> This still doesn't solve your problem, we'd have to define what the
> security context is, (a user id, a processgroup id, session id, pag?)

I would like to make a remark.

I find all security contexts other than uid - in *nix-like systems -
questionnable, both process group, session, pag.

Say, in a rather common setup with a home directory on a local file system
(which uses uid+group as credentials)
all processes with the same uid can potentially influence each other
by modifying files in the home directory - as the home directory is normally
used to find [references to] resources, via dotfiles and alikes.

So if you want to run a session as a separate security context, you must
ensure that no program run in that session uses things in the home directory
or anywhere else where the corresponding resource can be manipulated by other
processes of the same uid and different session/process-group/pag.

With other words, for a "credentials kind" to be reliable for protection,
the whole system must be designed/built around this credentials kind.

*nix protection model, the system calls and the whole architecture are built
around uid as the main credentials. There is normally no real isolation
between security domains defined in terms of other credentials like pag.

Regards,
Rune