On Mon, 16 Nov 1998, Eric Warnke wrote:

> I have been following coda development and have 2 question that appear
> to have gone unanswered in the list over the past year.
> 
> 1) Batch / Non Interactive
> 
> How do batch / cron / servers / etc... processes interact with coda. 
> The html files have a .rhosts file, does this mean that that 25hr token
> can be avoided?  How do daemons ( say backup ) interact with the cache
> if they do not have a token.  Ideally is there a way to just trust all
> users from an IP address assuming the system keys match.

I'll first address how these things work generally today (and in AFS
also).  It usually consists of storing the key to be used on the client,
and having a process refetch tokens on a regular basis.  I believe a
program called 'reauth' is used for this in AFS -- it would be trivial to
write a similar program under Coda, that retrieved tokens, and then forked
to re-retrieve them whenever they expired.  In general, unless ACLs are
set fairly uselessly, an unauthenticated user (that is, without tokens)
can do very little.  Currently the generate of backups involves cloning
the volume, which is an administrative function that occurs on the
servers.  In AFS, the volume utility uses normal tokens (well
adminstrative tokens) and can occur from any client.  No doubt as the
authentication system in Coda becomes more sophisticated, we will move in
a similar direction.

To answer your question about easy fixes for unauthenticated users on
trusted hosts:  I have been considering introducing a 'host key' anyway
for use prior to the first user authentication.  The 'host key' I was
thinking of would allow the establishment of authentic connections with
the Coda server via pseudo-tokens, but that the pseudo-tokens would not
actually provide any authentication or authorization as far as the server
was concerned.  This would prevent attacks resulting from cache stuffing
prior to authentication.  This is actually most useful in the case where
tokens expire for an existing user: the user does not immediately notice
that their tokens have expired, and the connections used to service their
file requests are switched to unauthenticated connections.  Their
connections can now be hijacked/etc, and things stuffed into the venus
cache on the machine in an unauthentic way.  Right now, this is a
meaningless distinction, as the security in RPC2 is just a framework. 
With the crypto work underway, this becomes a useful issue to fix :-). 

Adding host key trust in the style of NFS is fairly easy to do -- it
requires a few patches to the auth server to allow the acquisition of
tokens for any vice id given that key; similarly, it would require
modifications to clog to know how to do that, and then making clog setuid
or setgid so that it could access a key cache on the client that normal
users on the client could not access (that is, so that joe user would be
automatically authenticated with joe-user-tokens, but could not retrieve
system-administrator-tokens).  This would give you NFS-style trust of a
particular host (or at least, a host with a particular key).  This is not
a great thing, in that most people believe that the host-based trust model
of NFS is upsetting inadequate.  On the other hand, it is very useful in
the real world (such as in trusted environments, with ip filtering, etc).

I wouldn't guess patches to do this would take more than a few hours to
write.  I may take a look at doing that (since it seems useful, if
inconsistent with the Coda security model :) next weekend, depending on
how my current workload goes.  If someone else feels like implementing
them first, I can provide pointers.

  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/