Coda File System

Re: acl "transitivity"

From: <u+codalist-wk5r_at_chalmers.se>
Date: Wed, 27 Jan 2010 14:16:54 +0100
Thanks Satya!

On Tue, Jan 26, 2010 at 02:00:24PM -0500, M. Satyanarayanan wrote:
> Protection in Coda is unchanged from AFS.  See Section 6 in the paper at 
>    http://www.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/sec89.pdf

Strictly speaking, certain details described in the paper do not apply,
so a novice reader should take it as a general introduction but not
as a practical guide.

To name a few differences:

- root on workstations is not an exception from security point of view,
  in contrast to the approach described in the paper
 (authentication of root processes does not necessarily present a security
  problem, especially since tokens can be acquired anonymously via
  a public-key-authenticated channel)
- there is no support for setuid, nor the workaround "stem" user in Coda
- locking is not supported and consequently neither lock(k) privilege
- modification of programs like "ls" is no longer applicable
  as Coda is not a part of a full and centralized environment like
  AFS was under Andrew (note, the historical exposure of the internal Coda
  uids in the result of stat() is no longer useful as they never can be
  synchronized with the local uids on workstations, unlike Andrew),
  Coda assumes zero client-side administration
- Coda is not using PAGs (this makes reauthentication and security semantics
  straightforward, PAGs are often an inconvenience while they do not
  provide proper separation, nor have they compatible semantics
  on different platforms and in different people's minds),
  for differing access privileges at the same time one must use different
  local uids authenticated differently.

Besides the possible few differences it is an excellent paper to read
for understanding of the protection model.

Regards,
Rune
Received on 2010-01-27 08:17:29