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. 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?" 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?" For this particular functionality the consensus as I read it is that the community does not believe that this functionality is something that most sites would want to use. Neither is the community prepared to revoke the availability of the site local ACL bits. > 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. 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. 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. 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. > 2. insisting on ACL uniformity across sites is a neologism (some large > sites have historically wanted and created local policy in this area, so > the conservative position would appear to be, to continue to support it) The OpenAFS community has inherited many decisions from Transarc/IBM AFS that we continue to support. Site local ACL bits are one of them. The community has not indicated that it is not prepared at this time to revoke the availability of the site local ACL bits. Therefore, they are still available to sites that want to use them. 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. > 3. OpenAFS has an interest in making life easier for site administrators > where possible--removing the need for one site-local patch and test > cycle may seem like modest savings, but removing the need for several > could easily sum up to significantly reduced cost administrative cost Unfortunately, the reality is that increasing the complexity of the OpenAFS build system to support site local patches 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. 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; and (b) send a message that the functionality is tested when it is in fact not. > Again, I don't have very strong feelings about the feature per se, but I > would like to find ways to be more flexible with regard to site specific > customization in matters of administrative policy, and to sites' > perceived special needs, rather than less. 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. Jeffrey Altman (speaking in my role as OpenAFS Gatekeeper)
smime.p7s
Description: S/MIME Cryptographic Signature
