Site Specific ACL Bits/chown: Was: [OpenAFS-devel] posix chown again

[Simon Wilkinson]

On 8 Dec 2008, at 17:46, Jeffrey Hutzelman wrote:

>> and "is the OpenAFS community prepared to revoke the site
>> local ACL bits so that there are bits available to assign to a  
>> standard
>> function?"
>
> No one's suggesting that should happen.

This has been discussed. I don't think anyone believes that it's a  
realistic option at this time, but it's certainly been bandied about.

>> It is perfectly reasonable for different cells to apply different
>> policies.  It is not reasonable for different cells to use different
>> protocol semantics.
>
> Nonsense.  Different sites use different semantics in all sorts of  
> protocols, all the time.  If that weren't the case, there would not  
> be any need for private-use values in protocol fields.

Remember, we're not just talking about different sites, but also about  
potentially different semantics amongst servers at the same site.  
We're also talking about a situation where the meaning of a private  
use value can differ between two otherwise identical builds of the  
same product, at the same site.

>> Changing the meaning of an ACL bit from one cell
>> to another is the equivalent of changing the protocol not to mention
>> the user interface.
>
[...]
>
> It doesn't even change the user interface,

Consider how this looks to a user. They don't go "I'm setting bit 'A',  
which is a site-specific bit and I'm in cell X.COM, so that means  
<blah>". They think "I'm setting bit 'A', which means <blah>, because  
that's what it has meant every other time I've set it". AFS has enough  
usability issues for users - let's not add new ones.

> which always presents these bits as ABCDEFGH, regardless of what  
> they mean.  If you think that's too confusing, I could certainly  
> work up a proposal for protocol extensions to allow clients to  
> discover more descriptive names for these bits, though I have no  
> idea what the UI for 'fs sa' would look like, or what a reasonable  
> implementation in OpenAFS would look like.

Such an extension would remove some of my concerns - but rather than  
as an optional extra, I'd say it's pretty much essential to have it  
before this kind of feature is implemented.

>> A user or admin that works in two cells should not have to double  
>> check
>> every time they set an ACL how the ACL bits are interpreted in that
>> cell.   It is fine for a cell to decide to activate or deactivate
>> particular bits, it is not fine for cell administrators to decide  
>> what
>> the meaning of a bit should be.
>
> Too late; that ship has already sailed.  The very existence of site- 
> specific ACL bits is a statement that it _is_ fine for cell  
> administators to decide what the meanings of those bits should be.   
> That decision was made, and the bits were being used, long before  
> the OpenAFS project was started.

But the use of these bits isn't incorporated into the OpenAFS code.  
Using site extension bits currently requires that an administrator is  
very aware that they are deploying a local extension, and of the  
ramifications of doing so. Incorporating these extensions into OpenAFS  
normalises their use, and I think that is highly undesirable. In my  
view, the use of site local bits should require site local patches.

>> Unfortunately, the reality is that increasing the complexity of the
>> OpenAFS build system to support site local patches
>
> No one's suggesting increasing the complexity of the build system.

The core problem is that it increases the complexity of building, and  
deploying OpenAFS. You now have to ensure that all of your fileservers  
are built with the same set of options. If they're not, you have to be  
careful of moving volumes around between fileservers. This isn't a  
huge issue when you're just discussing one site-local bit. But, when  
we've got one, why not accept more? And then you really do end up with  
a twisty-turny maze of configuration directives. Building and  
deploying OpenAFS is complicated enough already - let's not make it  
more so.

> No, it doesn't ease the testing burden, much.  But it _does_ ease  
> the maintenance burden, because it means I don't have to spend days  
> hand-integrating changes before I can even begin testing.  As I  
> said, I've been there, and I don't ever want to go back.

If the code is never built, how can you tell that it's still working?  
I've been pushing for a while for a reduction in the number of -- 
enable- options, especially for little used code. If we're going to  
move forward into a world where automated regression testing is the  
norm, this is going to be more and more important - we simply won't be  
able to build, let alone test n^2 different configuration sets.

>> In order to add new ACL bit assignments to OpenAFS either the  
>> community
>> needs to revoke the availability of the site local bits or we need to
>> alter the protocol in order to support a larger number of bits.
>
> Or, the community could decide that the proposed approach is just  
> fine.

They could. We've heard from a number of voices against the proposal.  
It would be interesting to hear from people who believe both that  
integrating this patch is a good idea in theory, and who would in  
practice use it at their site. You are arguing that there's no  
consensus against this patch, and that may be true. However, there  
certainly seems to be no consensus for including it at the moment.

Cheers,

Simon.