On Tue, Dec 02, 2003 at 10:53:52AM +0000, Joerg Sommer wrote:
> begin  Lionix <lio_at_absium.com> wrote:
> >>I read in any documentation coda respects the unix permission of files.
> >>Is this correct?
> >>
> > No, you can't use chown / chmod to manage permissions, they are provided 
> > by the ACL and unix permission are not used anymore . Even if a file is 
> > root:root 600, everybody can read the file if directory is ACL-readable..
> 
> Are you sure? http://www.coda.cs.cmu.edu/doc/html/manual/x237.html says:
> 
> "In addition to the Coda access lists, the three owner bits of the file
> mode are used to indicate readability, writability, and executability.
> You should use chmod(1) to set the permissions on individual files."

Security is enforced by the server based on the ACL and the identity as
provided by the user token. Because some Unix applications don't like
non-Unix semantics, the client limits the current ACL permissions based
on the owner bits of the unix permissions.

So if the ACL allows nothing, you can't do anything.
If the ACL allows everything, you can do as much as the owner bits
allow. (i.e. 400 -> you can only read the file, 200 -> you can only
write, etc)

Owner/group information really means nothing. Coda doesn't care whether
root or nobody or whoever is considered the file owner. It is typically
set to the Coda userid of the last user who modified the file, but this
doesn't necessarily have to match the local userid. The kernel module
tends to cache the local userid. So if I create a file, it will
initially show up as owned by 'jaharkes' (uid 1000), then after the
cached inode information is dropped from the kernel and I look at it
again it will look like the file is owned by uid 7768.

> BTW: http://www.coda.cs.cmu.edu/doc/html/manual/x197.html says a tokes
> expires after 25 hours. Is this tunable? How to grant access for system
> services like apache? If users have in their home a webspace ~/.www/
> which is accessible through http://www.foo.de/~user/. So apache needs a
> unlimited token. Is this possible?

No. The Coda token is used to negotiate encryption keys used for the
RPC2 connections. The idea here is that by getting a new Coda token, you
invalidate all old connections and keys which adds a limit to the
usefulness of breaking the session key of a connections. But you could
compile clog and auth2 with kerberos5 support and then use

    clog -kerberos5 user_at_coda.realm

and it would try to get a Coda token based on your existing kerberos
credentials.

On our Apache server I'm running a small cronjob

    # refresh apache tokens once every twelve hours
    55 */3 * * *    root    clog -as www-data websrv < /etc/clog/websrv

The -as flag is relatively new, you might have to use "su -s/bin/sh -c'clog ...'"

> >>Is it possible to deactivate the cache on the client machines at runtime?
> >>
> > I would say no.. caching mecanism is a full part of the coda client ( 
> > venus ).
> > Why would you like to do such a thing ??? You can define the size of the 
> > cache in conf file.
> 
> Well, cache isn't the right word. I mean the disk cache. I would like to
> turn them on and off at runtime like a swap partition.

No, the 'cache' is accessed directly by the kernel. If an application
opens a file in Coda, we simply hand over an open file descriptor. The
kernel then does all the read, write and mmap operation directly on the
underlying file. Only when the file is closed do we actually tell venus
again.

Only open and close are thus slowed down by the context switched to the
userspace cachemanager, but all read-write traffic is just as fast as
the native filesystem that is used to back venus.cache.

Jan