Hi,

So you want a sticky bit on the directory.  Not a bad idea - this is
also quite desirable for email spool directories etc.  This is one of
the main problems of the AFS/Coda security model.  Where it tries to
diverge from Unix it runs into trouble in system directories like
"mail", "/tmp" etc. where sticky bits are used.  But it is pretty easy
to change Coda a little bit and perfectly acceptable, to accomodate
this.  

Clearly what you want requires making a distinction between the owner
and others. For this to make sense, "owner" must represent a "coda" uid
and not a Unix uid.  The kernel however creates files with the Unix
"uid" so that will need fixing up in the "create and mkdir" upcalls.  
They will return the attributes of the created file and the kernel
should set the owner to the Coda uid. [Although one could also argue
that there are two owners and the kernel sees a Unix uid while Venus
only sees a Coda uid -- that's getting pretty confusing though.].

Next, we must prevent chown - probably chown should require "a" rights
on the parent.   So "chown" will be allowed when administrative rights
are present on the directory - that makes ownership a protected
property.   

Our ACLs won't do what you want - so we'll have to rely on the mode
bit.  So "chmod" similarly should not always be honoured, only with "a"
rights on the parent.  This is currently not done, and requires a few
extra lines in vproc_vfscalls (setattr ~l 430), to find the parents and
check the rights.

So the picture would be roughly as follows: when you want to delete a
file or remove a directory, we require rights on two objects: the parent
and the child (you are changing the link count of the child).  

On the parent, the "d" ACL field should be set, this is already checked
in vproc_vfscalls.cc line 771.   We could regard changing the link count
as having a "w" bit on the child. So we add a line (772 or so) requiring
that. That would fit well.    So if the caller has "w" rights we let it
go through, and the caller doesn't we don't.   [This also can disallow
writing by others (but you might have to look at the "open" calls to
make sure it is enforced), and sensibly, if writing is allowed by
others, the file can be removed too.] 

Things like this werer already done in AFS but the code for it in Coda
is commented out (around line 350 in coda-src/venus/fso_cfscalls.cc).  
Reading Satya's AFS security paper, the protection was put in place to
prevent accidental deletions - by "anyone", now we are refining this to
use the owner.

Also it looks like the old AFS mechanism was not quite done in the way
we want it now, since the "vuid" is not taken into account when looking
at the mode bit.  The usual macros munging on the bits in mode while
comparing the "vuid" (the identity of the caller) and the "owner" must
be taken into account. 

So I think this is an excellent little hacking project, to adapt
fsobj::Access to do exactly what you want.  I think it's not too much
work to do this.  If you do it send us the patch, then we'll put it in. 

- Peter -




Simone Celli_Marchi wrote:
> 
> On Wed, 28 Apr 1999 jaharkes_at_cs.cmu.edu wrote:
> 
> > | I have a volume named public mounted in /coda/public and a group
> > | called public. I want that all user belong group public can write in /
> > | coda/public but can't delete file of other users. Is it possible
> > | without set a acl for any user ?
> >
> > Well, you can set an ACL for a group of users, or in your case
> > System:Anyuser, the group of all users.
> >
> > So something like `cfs sa /coda/public System:AnyUser rwil' should do
> > the trick.
> 
> But in this way a user can't delete own files !