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

[Jeffrey Hutzelman]

--On Monday, December 08, 2008 08:17:23 AM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> Matt Benjamin wrote:
>
>> Although I follow this reasoning, I'd at least tender the possibility
>> that the following reasoning is at least equally plausible, disregarding
>> for the moment the current scarcity of ACL bits:
>
> Unfortunately, the scarcity of ACL bits is one of the significant issues
> associated with accepting this patch.  If we had a bit that we could
> assign to it, then we would accept the patch based upon the merits of
> the functionality and the quality of the patch.

Matt very carefully tried to avoid the question of scarcity of ACL bits and 
address the larger question of whether it is appropriate and useful for 
OpenAFS to contain code that is useful to and enabled for some sites but 
not all, or whether we will force anyone who wants a site-specific feature 
to take on the burden of maintaining a local patchset and updating it for 
each new version.

I know where I stand on that question.  I maintained a fairly extensive set 
of site-specific patches to AFS throughout most of the 1990's.  One of the 
first things we did when we started the OpenAFS project was to apply a 
number of site-specific changes and other improvements that various sites 
had collected over the years but which had never made it upstream.  Life 
had suddenly become a lot easier for many of us.  I used to maintain around 
20 site-specific patches for AFS.  Today I maintain three:
- find compilers where we put them
- change how AFS_component_version_number is formatted
- support for a local ptserver extension involving a large hash table
  of IP addresses, which I haven't figured out how to generalize

I don't want to go back to the old way, and I don't want to force others to 
experience that pain, either.




Unfortunately, you've decided to ignore that question, and talk about the 
scarcity of ACL bits.  Fine.

The proposal was not to allocate a non-existant ACL bit.  The proposal was 
to add a feature which, if enabled, uses one of the site-specific ACL bits, 
and to determine which bit to use at configure time.  This puts the code in 
OpenAFS, where it's easy to maintain, and the allocation of site-specific 
ACL bits in the hands of server administrators, where it belongs.



> Since such bits are not available, the questions then become "is this
> functionality something that the vast majority of sites would want to
> make use of?"

That doesn't follow.  Sites that don't want this functionality don't have 
to turn it on, and there's plenty of precedent for building in features 
that most sites don't turn on.


> 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.




>> 1. it is in fact reasonable for different access control policies to be
>> applied in clearly distinct administrative domains (the definition of an
>> AFS cell);  Viewed in that way, it seems quite illogical to invoke "the
>> principle of least surprise" as an argument against site-specific ACL
>> behavior
>
> 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.


>  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.

Actually, it doesn't change the protocol at all.  The protocol defines the 
bits in question to have site-specific meaning; anyone who depends on their 
semantics without knowledge of what they are being used for deserves what 
they get.

It doesn't even change the user interface, 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.


> 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.

> In this regard the "site local ACL bits" are a usability nightmare
> and in my opinion they should not be used at all UNLESS the cell is
> operating in a private name space disconnected from the global AFS
> name space.

Frankly, as a site administrator, I don't think your opinion is a viable 
substitute for my reasoned analysis about what my requirements are and what 
I need to do to satisfy them.  If you don't want to take this patch because 
you think it's too complicated or too hard to maintain or doesn't do what 
is intended or is too marginal, say so.  But you're saying you don't want 
to take it because site administrators shouldn't be allowed to use bits set 
aside for their use, and that's just silly.


> That does not imply that the OpenAFS community encourages their use
> nor does it imply that the OpenAFS distribution should make it easier
> for cells to shoot themselves in the foot.

No, it doesn't.  But the OpenAFS community is capable of making decisions 
for itself.  The topic of usability and management of site-specific ACL 
bits is not one that the community has ever discussed, to my knowledge. 
Please don't take your opinion on the topic and present it as the consensus 
of the community.


> 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.
Adding a --enable-foo switch and a corresponding ENABLE_FOO preprocessor 
macro does not increase complexity; it takes advantage of functionality 
that is already there.  We can have any number of such things without any 
change in the complexity of the build system.


> will not ease the
> testing burden of organizations that wish to make use of those patches
> unless the OpenAFS gatekeepers were willing to take on the
> responsibility for testing those site local configuration options with
> each release.  Each new feature that is compile time configurable
> requires a separate set of testing with that option turned on and off.
> Adding multiple site local configuration options means that each
> combination of option must be tested.

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.


> The OpenAFS gatekeepers and the broader community are in no position
> to perform such testing.  As such I believe it would be irresponsible
> to accept such patches into the source tree.  Doing so would do nothing
> more than (a) send the message that using the site local ACL bits is a
> good idea

Again, that ship has sailed.  You've said you think it is a bad idea for 
sites to actually use site-specific bits, but I see nothing resembling a 
community consensus behind that position.  So, I fail to see the value in 
an argument that something should not be done because it fails to send that 
message.



> and (b) send a message that the functionality is tested
> when it is in fact not.

This, in fact, is the only meaningful argument you've made yet, and the 
only one that actually addresses Matt's original post, instead of going off 
onto the tangent of whether and how to assign site-specific ACL bits.  I 
think that's unfortunate, because the real issue here is not about ACL 
bits; it's about the extent to which OpenAFS should accept and maintain 
code that is not turned on in every build.

I think that is a fundamental question about the philosophy of the project, 
on which we need to have a real community discussion, rather than having a 
few individuals make decisions by fiat.



> 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.

-- Jeff