(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-12-05 17:28:11