Jan, thanks for your extensive answer - but still a few questions remain:

On Thursday, 08. April 2004 06:32, Jan Harkes wrote:
> 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.

This is really fine, since I am using ldap for all of this, but using nss 
there is no difference between that and /etc/passwd. So  - how much work is 
to be done to move the coda-database to ldap?

>
> > - 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.
>
How does coda get to know this mapping? On which basis does it map? I thought 
it was the uid, but that doesn't make sense anyway...

> 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.
But what happens if you get disconnected? In what way is access control done 
on cached objects or for creating new objects?

BTW - where will I get in trouble when using large caches (e.g. > 1GB on 
laptops)?

> 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.
Of course, this makes sense (on every pure fileserver users should be denied 
local access!) and is in fact great! 

> 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.
>
My users will like to be able to change access rights on their files (e.g. 
what about making files executable) and e.g. give a virtual group access to a 
project - how could they do that? Furthermore they probably prefer to do it 
using chmod/chown ...

Thanks once again,
Michael