On Thu, Apr 08, 2004 at 02:37:58AM +0200, Michael Tautschnig wrote:
> Since I intend to use Coda in a production environment, I need to know a lot 
> more about the mapping of uids/fileowner between getent()-results (e.g. /etc/
> passwd) and coda's own database.
> 
> - What was the idea when creating an independent database (obviously 
> administrative work increases...)?

Clients are untrusted. Local userid's are irrelevant. Large
installations typically already have some sort of an independent
database (ldap, nis, mysql, pts) and the idea was that the interface we
use to access the pdb database would be abstract enough to allow Coda to
hook into any existing systems.

> - How can I change a file's owner/group according to coda-numbers
> (e.g. change group to -3 ?)

The Unix userid and groupid is totally unused, we don't even send the
groupid information in the SetAttr/GetAttr rpc calls. When a file is
created the userid is set according to the Coda userid of the RPC2
connection, although the locally cached copy initially will have the
local userid. i.e. my local userid is 1000, my Coda userid is 7768. So
when I create a file it will initially have uid 1000 on only my client,
everyone else sees 7768, as will my client if it ever replaces the
cached copy.

The Unix modebits are only used to some extent, mostly to refine the ACL
permissions a bit. If the user write bit isn't set the file cannot be
written even when the ACL grants those rights. The AFSified version of
'ls' doesn't even show gids or group/other modebits.

For the rest, all security is based on the directory ACLs in combination
with the authenticated Coda userid. That is, if my local userid has a
valid token, venus will use only RPC2 connections to the server that
were set up with my token. So the server knows that al my requests are
performed by user '7768', and will tell my client what rights _I_ have
to the object I am fetching given the security context of my connection
to the server.

When another user tries to access the same object, he will use his
authenticated connection to get his access rights for already cached
object. If there is no connection his access is denied.

So a Coda client doesn't try to interpret the token we give it, and
doesn't interpret ACLs as it really has no (reliable) clue what our Coda
userid is or which Coda groups we are a member of.

There is also no sane way to map Coda userid's to local users. My Coda
user is different for each realm, I can have multiple local users that
use the same token. And in the original design of the security model
(using process authentication groups) one local user could have multiple
simultaneous sessions with different tokens. Also there are many users
who have an account in our Coda cell, but only I have access to my
laptop or desktop and I'd like to keep it that way. This also means that
there is no usable local userid in my /etc/passwd that would match
satya, or shafeeq, or other local Coda users.

And if I get an account on, for instance, your realm, I don't have to
add all your users to my local /etc/passwd file (or deal with all the
userid conflicts).

Maybe Coda should always return a fixed userid in a file's attributes
similar to the fixed groupid (65535 or something) we already have. But
sadly a lot of installers (rpm/dpkg/install.sh) tend to fail when we
don't appear to listen at least a little to chmod/chown syscalls.

Jan