[118] in DCNS Development
Re: Directory protections in AFS
daemon@ATHENA.MIT.EDU (John Carr)
Tue Sep 24 13:22:56 1991
To: nschmidt@Athena.mit.edu, developers@Athena.mit.edu
In-Reply-To: Your message of Tue, 24 Sep 91 09:06:33 -0400.
Date: Tue, 24 Sep 91 13:22:07 EDT
From: John Carr <jfc@Athena.mit.edu>
I brought this up at one of the AFS meetings. I thought it was a serious
problem with moving users to AFS but others seemed to think it could be
solved by user education.
We have to decide: are we going to run Transarc AFS with all its flaws, or
something that works but isn't fully supported. We have been taking the
second option, but I don't know if this has been blessed as policy (official
policy tends to equate "vendor supported" = "superior").
If MIT is going to run something other than standard AFS 3.x there are three
choices:
1. Make minor enhancements to AFS to make it work better here
(ex: subnet biasing).
2. Make major changes to AFS, probably at the cost of reduced
interoperability with sites running standard AFS
(ex: execute-only directrories, inherited acl != directory acl).
3. Wait for AFS 4.
In my opinion, item 1 is insufficient. AFS could be modified to work "good
enough" (item 2), but this would require a major change in DCNS policy and
there may not be enough programmer time to make the changes. Waiting for
AFS 4 would be a good strategy if we could count on it working. The
descriptions I've heard make it sound as if it will solve all the world's
problems, so I'll believe in AFS version 4 when I can use it and not a
moment before. There is also some doubt that we will be able to use AFS 4
in our environment. Note that Transarc won't change AFS semantics in
version 3 because everybody is supposed to be running version 4 Real Soon
Now (I'm reminded of a phrase I heard when I worked at IBM; it was used to
kill projects that upper management felt would compete with some other
policitially important project: "that's not strategic").
I feel we have to commit to running a substantially different version of AFS
(either 3.2 + athena or 4.0) before we can move all users to AFS. Now is
not too soon a time to plan what that will be: whatever AFS software we'll
run next summer will need to be ready for testing around the end of March if
we are to have confidence in it.
