Jan,

Thanks for your continuing interest. I think you are hitting
interesting points. 

The Coda security model is like Kerberos: root on a workstation is not
considered a secure user. When systems scale to 1000's of clients or
more, one simply cannot be certain about root users, and they become
the anonymous hacker's default account.

The ACL's will NOT allow root to write, or even look at files, unless
the powerless unauthenticated System:Anyuser group has such
permissions.  Even installing a user "root" (which I DO NOT recommend
will probably not get you past this issue in the authentication
protocol). However when a volume is first created is has all
permissions, to be fixed by the sysadmin when mounting it. (BTW, the
permissions are independent of the mounting point, although access to
the mounting point depends on further ACL's.  BTW, this is not
dissimilar from mapping root to nobody under NFS.

The issue of reintegration and tokens is quite interesting.  I'll try
to briefly summarize Jay Kistler's thesis, section 7.2.1 where the
matter is discussed: look at 
http://www.cs.cmu.edu/afs/cs/project/coda/Web/docs-coda.html
(towards the bottom are the PhD thesis).

Coda allows (should allow??)  only a single user to make modifications
during a session of disconnected operation.  Further users will get
permission denied errors.  The reason is - roughly - that otherwise
the reintegration for user A may have to wait until B is done, which
is impractical.  Tokens are needed before this reintegration can take
place.  And now there is a BUG that you spotted: either we should
disallow unauthenticated modifications during disconnection, or we
should reintegrate them "unauthenticatedly", and currently we don't.
So the root modification log never makes it to the server which is not
good.

On the issue of UID's for Coda and Unix, you are quite right.  We
should (and will) have a translation table for Coda uid's to Unix
uid's, particularly when we will have cells (which we are working
on). 

Regarding your last two points.  If anything, root has less
permissions than other users for file system operations, but root has
priviliges of manipulating the settings in Venus (using vutil and
perhaps cfs).  As for papers about this the following are interesting:

- Integrating Security in a Large Distributed System
     Satyanarayanan, M.
     ACM Transactions on Computer Systems
     Aug. 1989, Vol. 7, No. 3, pp. 247-280

- Kistler's thesis: 
Disconnected Operation in a Distributed File System
     Kistler, J.J.
     School of Computer Science, Carnegie Mellon University
     May 1993, CMU-CS-93-156
     Abstract, Full Text 

- A little Coda internals document I wrote.  I'll send you that under
separate cover (we will put them all on the WWW pretty soon). 

I hope this helps.  Thanks for playing with Coda.

Peter 

J. A. Harkes writes:
 > Whenever as root, I try to do `clog <valid user-name> <password>' I get
 > the message `root cannot acquire Coda tokens'.
 > 
 > Under normal Unix semantics, the root account can always obtain access
 > to any uid. I know that being root on the client is not equal to being
 > root on the server, but when I provide a user-name/password combination
 > I expected to get a token for that user-name on the server.
 > 
 > This is especially strange because root can write to the coda file-
 > system, but his changes are never reintegrated because of `pending
 > tokens for uid 0'. Am I doing something terribly wrong??
 > 
 > And, although Coda-uid's are totally separated from their Unix
 > counterparts (own password file etc.), there are many grey areas where
 > it is assumed that coda-uid's match the client's Unix-uid's. Isn't it
 > possible to map coda-uid's to the client's Unix-uid's, or should I
 > always keep vice's password file synchronized with the system password
 > files?
 > 
 > In the Venus source there is a V_UID (==root-id) and a routine
 > AuthorizedUser() which are used for authorization checks. It seems like
 > root does have some special permissions, but when are those applicable?
 > 
 > Is there any documentation available that could answer some of my
 > questions?
 > 
 > Jan Harkes <jaharkes_at_cwi.nl>
 > 
 > 
 > 
 >