On Tue, Jun 12, 2001 at 11:51:12AM -0400, Zac Mouneimneh wrote:
> Hello!  I have successfully installed and configured coda 5.3.14.  I am
> trying to make my users home directories available through the Coda file
> system, but have not been able to figure out how to do this.  Is it at all
> possible?

Only by copying these home directories into /coda using a Coda client.
We need a lot more (reliable) information than is stored in a regular
filesystem to support Coda's replication features. The on-disk layout of
files that Coda servers use has no relation to the namespace as seen
through /coda.

As /coda is filled with files from a client, /vicepa on the server is
filled with files like /vicepa/0/0/1 etc.

> Will future releases of Coda have the capability of getting its
> username/password list from the Unix /etc/passwd file?

Coda used shared secret authentication, in our case the cleartext
password is the one that both the client and the server know about and a
challenge-response handshake (modified Needham-Schroeder) is initially
used by both sides that they know the secret without revealing it.

Because both sides need to have access to the 'authenticator' (shared
secret), the /vice/db/auth.pw should be readable only by the auth2
daemon. A normal /etc/password file contains the hashed version of the
user's password and doesn't reveal much about the actual password and we
wouldn't be able to use the actual password as the authenticator (unless
we send it over in the clear). We could use the hashed value, but this
information is available to any user and when everyone can easily access
the shared secret it has lost it's usability as the authenticator.

We could potentially rely on the secrecy of the authenticator when
shadow passwords are used. But this is hard to enforce, and it is too
simple to switch back and forth between normal and shadow passwords. As
a result someone might have already grabbed a copy of the 'open'
version.

Besides /etc/password is specific only to the local machine. I wouldn't
want someone to create a 'valid user account' for jaharkes on his
machine and then be able to read my mail in /coda. That is not security.
It is simply better to leave Coda's authentication out of the local
system's authentication loop.

> Also, my client machines all use a Linux installation that is NFS mounted
> on my server.  (nfsroot w/ devfs)  If I try to use the Coda client on
> these machines, I am unable to write data to any files.  Will this be
> fixed in future releases of Coda?

Well, where do you think Coda stores the files that are cached in it's
persistent cache? /usr/coda/venus.cache, if this directory is in the
nfsroot fs, there is a problem. It is possible to change this path to
/var/cache/coda in /etc/coda/venus.conf (at least /var should be a local
disk...)

Coda needs to have the venus.cache and the RVM log and data files on
some stable local storage medium. We allow write-access even when
disconnected from the network, files that are read and their updates are
stored in the venus.cache directory. Even when a machine is rebooted
these updates are not lost. Whenever this cache is stored in
nfs/ramfs/tmpfs, it becomes pretty hard to do either the 'disconnected
access' or the 'persistent across reboots' parts.

There is a good chance that storing a cache in NFS will actually work at
some point, as long as the network is available. But I wouldn't call it
a fix, it's more like allowing people the full freedom to shoot
themselves in the foot. Hmm, maybe at some point someone will try to
actually store the venus cache in /coda.

Jan