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

[Simon Wilkinson]

On 9 Dec 2008, at 16:32, Matt Benjamin wrote:
> In general, I am of the belief that prescriptive rules, here
> specifically, the proscription sites _should not have_ site local ACL
> bits,

I'm certainly not saying that sites _should not have_ site local ACL  
bits. Sites are free to do whatever they like with the site local  
bits. What I'm arguing is that OpenAFS should not ship with a  
mechanism to allow sites to assign a meaning to an arbitrarily chosen  
one of the site local bits by flipping a configuration flag, without  
reconciling the security and usability issues that this presents.

> Rather obviously, it should take more than a simple majority of folks
> not seeing the purpose of some feature, when one of the largest and  
> most
> significant OpenAFS deployments historically and today, worldwide,  
> sees
> its merit enough to code and maintain it.

Is there merit in adding a new feature to OpenAFS simply because a  
single site requires it, when that feature is implemented in such a  
way as to impede the usability of OpenAFS as a whole? Surely the way  
forwards here is to explore ways in which this feature can be  
implemented so that it doesn't impact upon others. I suspect many  
would find the feature itself useful, but would not be prepared to  
accept the maintainance and usability burden it brings with it.

> * The argument for "uniformity" and against site-local flexibility  
> seems
> to be a proxy for a much larger argument against diversity in the code
> base, against OpenAFS being more things to more people, where no one  
> is
> harmed--the shifting of the argument to be against "too many
> configuration options" is the evidence for this

There's pretty strong evidence that as the number of configuration  
knobs increases, the usability of a product decreases. The balance is  
finding the _right_ number of configuration knobs such that it is  
usable by all classes of users, from novice to experienced. You only  
need to read IRC, or the openafs-info list, to realise that the  
process of configuring OpenAFS is daunting for a novice user. If we  
want to expand our userbase, we need to tackle this complexity. This  
isn't to argue against OpenAFS being more things to more people, but I  
would like to see the number of incompatible choices reduced, and more  
code included by default in the stable builds (for example - why  
should a new user have to decide whether or not they need this  
'supergroups' thing? If it's stable it should be on by default, if  
it's unstable, it shouldn't be in the stable tree). I realise that  
we're not going to solve this problem in a day, but I think we have to  
start thinking more about how simplify adoption for new sites.

> Turning to that, the argument against "too many configuration  
> switches"
> is rather like the argument that Mozart used "too many notes."  Too  
> many
> for what?

Your analogy is flawed. No matter how many notes Mozart used, it was  
still possible to determine the quality of the resulting work.

> Clearly, we should keep all the switches activating the features that
> the product and its developers need--all the rest are superfluous.   
> Just
> as clearly, "too many configuration switches" is a proxy for blanket
> attacks on all the features _you_ don't see the need for, but others
> (who created them) did.

To be clear, I'm not attacking the addition of new features - I'm all  
in favour of them! What I'm against is the addition of code  
_particularly on the stable branch_ which is hidden behind arcane  
combinations of build time configuration switches. (Run time  
configuration switches are a slightly different matter). But the  
configuration switch issue is really just a symptom of why this patch  
is flawed, rather than the cause.

> OpenAFS gatekeepers don't need to test all the features the product  
> can
> theoretically perform, they only need to test the ones that are
> _officially supported_.  To argue otherwise is, respectfully, some  
> type
> of overreaching.

Ok. So there's a major philosophical argument here. Why would OpenAFS  
ship code that it doesn't support? If the code isn't supported at all,  
doesn't it belong in some kind of 'contrib' area, rather than in the  
main build. I think there's an assumption that everything in the  
OpenAFS tarball is supported, as much as any of OpenAFS is supported.  
As far as I'm aware, we're not currently listing a set of options that  
gives you a supported build, and declaring 'here be dragons' for  
everything else. However this is really beside the point - the patch  
isn't flawed because it adds yet-another-configuration switch, but  
because it does so without regards for the consequences of making this  
option configurable.

> But respectfully, we
> have, collectively, a right to expect the solutions to be the best
> available, to be sensible, flexible, and well reasoned.

My argument, as I've made before, is that the solution presented by  
the patch we're currently discussing is neither sensible, flexible nor  
the best available.

Let's consider the issues. The patch creates a compile time option  
which allocates a user determined site-local ACL bit to have a  
particular meaning. There is currently no way of guaranteeing that the  
bit that's been selected is consistent between sites, or even between  
file servers. This creates, as far as I can see, the following problems:

*) A user with a presence in multiple sites has to remember what each  
site local bit means in each site. Forgetting this meaning may lead to  
them setting permissions on their files which they didn't intend.
*) Systems staff building OpenAFS across a large environment must  
ensure that every fileserver build has the same set of configuration  
options. A failure to do so means that ACLs will silently change  
meaning when a volume is moved between servers
*) Systems staff upgrading OpenAFS must ensure that the new build is  
done with the same options as the last one. Failing to do so will  
cause ACLs to silently change meaning upon upgrade.

In my opinion, an acceptable patch would have to address these 3  
issues. I think it could do so by adding a mapping RPC, similar to  
what Derrick has already discussed to solve the first issue, and by  
having the ability to detect, and warn of, the latter 2 cases.

> I have always assumed the fair bargain for the right to add new  
> concepts
> and implementations to the system, was that I not act to _prevent
> others_ from adding features for which they see the need and benefit,
> but which I, in my ignorance, do not.

I think any successful large project has to have a group of people who  
take the broader view, and consider the impact across the entire  
system of new features. Some features may be of use to a single user,  
but damaging to the system as a whole. Part of the process is  
balancing the needs of the one with the needs of the many, which  
requires that, upon occasion, some modification of proposed new  
features is required.

> It is the responsibility of site
> administrators (or their contractors, or whatever) to establish and
> maintain a uniform deployment of OpenAFS servers--or indeed, to be  
> quite
> frank, their prerogative to establish and maintain whatever
> configuration of OpenAFS servers they darned well like.

I don't agree. You're suggesting a utopian scenario which doesn't  
compare with many of the site realities I've seen. How many times do  
we get messages from admins whose predecessors have installed an  
ancient OpenAFS, and they're looking to upgrade, but don't know where  
to begin? Building a successful product is about making it easier, not  
harder, for the users who are least able to help themselves.

> The premise that sites cannot be trusted to coordinate uniform build  
> and
> release cycles, such that uniform build configurations, and indeed, a
> uniform set of OpenAFS program binaries are in use at each release  
> they
> roll out, is simply not credible.

I think your experience of the world has been a little more cosy than  
mine. I can think of many sites that don't coordinate releases in this  
way. They probably should, but they don't, and that's the world in  
which we have to operate.

S.