Hi Alan,

On Fri, Feb 12, 2010 at 02:31:25PM -0600, Alan Caulkins wrote:
> I'm considering switching to Coda as an alternative to my current AFS
> cell, and I have a couple of questions about how Coda interacts with

At first a word of caution, Coda has more rough edges than AFS,
it has never got as much attention and polishing.
Coda is today "production-ready" if you know the internals and are
prepared to implement workarounds for hard-to-fix-bugs and
limitations, not otherwise.

"No writes to the same object from different daemon instances" is a must
for automated things. Humans shall be ready to deal with conflicts.

> certain services. Specifically, I'd like to know how service daemons
> authenticate themselves with Coda over time. In AFS, if I want a
> service to have access to directories (beyond the basic anyuser
> non-authenticated access), I have to set up a service principal for
> the service in Kerberos. That pricipal must then be authenticated with

I guess you are a bit confused by Kerberos terminology or otherwise
use the terms in a confusing way.

It is wrong to talk about "service principals" in this context.

If you want a process to access protected objects, you need an identity
for that process, such that the ACLS allow accesses for that idenity. You
need also a means to provide the credentials so that the process can
prove it belongs to the identity.

In AFS/Kerberos you need a principal and a corresponding account
and a password or a keytab.

In Coda you do not need to use Kerberos, Coda has its own password
database, Kerberos can be used as a complement but you don't
want it - good.

With both AFS and Coda you have to periodically refresh the credentials.

Note, there is no difference between a terminal session of a human
and a daemon process, all of the above fully applies in any case.

> Finally, AFS
> has a "process authentication group" (PAG), which is an AFS-specific

We are lucky - Coda does not use PAGs.

> 1. If I use Coda without Kerberos, how do I continuously authenticate
> long-running daemons? (I have come to view Kerberos as a problem, so I'd like to live without it if possible.)

Let some process running with the same uid as the daemon to do periodically
 clog .... <protected-file-with-password

> 2. Where does Coda store user accounts?

In a database managed with pdbtool on the SCM machine.

The passwords are managed separately, remotely, via au utility,
first you have to create a user record (in the separade password
database), then you can change its password with this utility as well.

> 3. Does Coda have something like a PAG, and if not, how does a process
> tree share authentication?

The credentials are bound to the process' uid.

> 4. Kerberos is intended for single-user workstations, and
> multiple-user workstations have security problems associated with
> their ticket stores in /tmp. Does Coda better deal with multiple
> simultaneous users on a client or does it have these same problems?

Coda has other security issues on multiuser machines, but not this one.

Depending on your needs those issues can be more or less important than
the storage of Kerberos tickets. The issues are somewhat shared with AFS.
I am not going to discuss them, there are lots of other Coda issues
more important for most people, almost certainly including you. :)

> 5. I've seen statements on the Coda website about server machines that
> are also clients not being recommended. There are also remarks about
> this being an old problem that is no longer so significant. What is
> the current status of this issue?

Forget this problem, nowadays it is no problem.

> Sorry that these questions are so lengthy, and thank you in advance
> for any information you can share.

Thanks for thoroughly formulated questions.

Regards,
Rune