On Tue, 24 Nov 1998, Jordan Mendelson wrote:

> I also have automated processes (web server) which must read those home
> directories and have access to the files (public_html).

It depends what you need here.  Coda recognizes as 'System:AnyUser'
identity in ACLs that corresponds to any unauthenticated user.  This is
similar to the use of the 'other' component of the UNIX file system
bitmask with regards to common web servers.  Because the web server
typically runs as its own user and group, the permissions of the 'other'
component address the rights of the web server with regards to the
directory.  However, it is slightly different, as any unfirewalled coda
client that provides no authentication gets this status, meaning that they
are no limited to merely what the web server allows.

Another common solution used by AFS sites is to have a specific 'www' coda
identity -- the web server authenticates itself as www to acquire tokens,
and then is granted the permissions the www user is provided in Coda.  The
downside is that this may require your users to be aware of the ACL
system.  The System:AnyUser solution can overlap with this, of course. 


> I also have the problem that auth2 has it's own password file and isn't
> using system database instead.

This is correct -- Coda requires access to a shared secret with the user
to perform an RPC binding.  The traditional password database keeps only a
one-way hashed version of the secret, so cannot be used easily.  We do,
however, support KrbIV and KrbV.  One possible answer to this problem is
to make use of one of these mechanisms, or use the Coda auth database to
generate password files and export them to your hosts using Coda.  If you
do this, you will want to make sure your ACLs are set right, and perhaps
wait for our encryption/authentication patches to be available (we're
guessing around 5.1 or 5.2).  As many systems that use password files make
no secret of the hash values of the password (i.e., no shadowing, or NFS
exporting), the hash cannot be used as the shared secret.  These one-way
hashes are only useful for very basic authentication on a local machine.

> Maybe CODA isn't a good replacement for NFS in this case.

Coda is fairly experimental at this point (heavy use may cause you to
encounter bugs, and performance is still being optimized), and it also has
a significantly different security model from NFS (that is, it actually
has a security model :).  As a result, it may not be appropriate for
production use just yet, but the future looks bright :).

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/