On Thu, Apr 08, 2004 at 10:45:12AM +0200, Michael Tautschnig wrote:
> > 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...

There is no "mapping". Your uid has Coda token corresponding to some Coda
identity (say identity presented by number 7768). Thus Coda remembers
the author of the file as "identity 7768".

Preferably avoid thinking "file owner" as it is misleading.
Coda uses ACLs, not rights bound to "file owner" and "file group".
So a file has no such attributes. Coda maintains the records who
created the file, like Unix, but it has nothing to do with the rights.
So while Coda can show that information through Unix - say via ls,
it does not mean anything about who has special rights about the file.
It is said instead by the acl attached to the containing directory, in terms
of Coda identities and groups.

> > 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

It is unfortunately implemented on the client side, so it is "wrong".
Anyone can run a client with modified venus and read or modify a file
according to the acl, even if modebits do not allow that.

Usable aganst shooting oneself into the foot but not much more.

> But what happens if you get disconnected? In what way is access control done 
> on cached objects or for creating new objects?

Venus caches access rights per object and local uid. Those rights are used
while disconnected. There was some recent discussion on the list.

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

I tested to fill 5G without a problem. You will get problems rather with venus
growing its virtual memory footprint and swapping...
So have lots of RAM if you want big cache.

> > 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! 

I guess you are talking about different things, and also Jan did not
clearly distinguish between directory information like uid<->name
(contained e.g. in /etc/passwd) and the right to log in - it is a historical
Unix confusion... as /etc/passwd is often used to give login rights too.
 
> 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 

Coda should always mark files as executables, imho :) Anyway, no problem
with bookkeeping the 'x'-bit. The rest should be done via acls.

> project - how could they do that? Furthermore they probably prefer to do it 
> using chmod/chown ...

They might prefer, but it is impossible, chmod/chown authorization model
is incompatible with Coda... Sorry, the base of the Unix authorization is
an idea of a personality having special rights on an object.

ACLs are a lot more general approach, so you could imitate chmod/chown
with some "cfs sa" wrapper - and then have to wrap "ls -l" as well...
And never be able to do like Unix - as Coda does not offer acls per-file.
Then the users would be helpless using another installation or another
Coda cell, or surprised when they encounter objects with acls not limited
by your "owner and group" simplification. I wouldn't recommend it.

Essentially, ACLs are more intuitive than Unix model, so let the users
see the better side of the world :)

Best regards,
--
Ivan