Site Specific ACL Bits/chown: Was: [OpenAFS-devel] posix chown again
Derrick Brashear
shadow@gmail.com
Tue, 9 Dec 2008 11:56:03 -0500
------=_Part_46578_32965787.1228841764075
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Tue, Dec 9, 2008 at 11:32 AM, Matt Benjamin <matt@linuxbox.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Simon,
>
> In general, I am of the belief that prescriptive rules, here
> specifically, the proscription sites _should not have_ site local ACL
> bits, disregarding precedent (the entire history of AFS), should have to
> meet a far higher standard than 4 people on this list oppose (while at
> least 3 have publicly supported, and more support is, of course, out
> there for this feature than has weighed in.)
>
Possibly also more opposition.
>
> 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.
>
> To me, the discussion on principle (and the principles of sound
> reasoning) are what matters. I think that anyone who read Jeff
> Hutzelman's post should have come away with the realization that there
> are important matters of principle at issue here.
>
> Here is my summary, amplifying it with some more:
>
> * OpenAFS needs to stay true to its history, as well as move
> forward--that means it needs to take account of the needs of sites like
> CMU and (redacted, their preference, this is Derrick's convention of
> representing it)--to do otherwise is really unwise (I easily could add
> more adjectives here)
>
> * 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
>
The poster child for complexity is Cyrus, which was, at its inception
elegant and simple. Now many people who could use its features sorely won't
run it because they're scared. I don't want to chase away users. At the same
time, it's important to support the things people need to do.
This is mostly orthogonal to the issue at hand.
>
> 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?
How many are needed versus how many could be elided if we did a better job
of representing what people want to do? For instance, -L was a good idea but
doesn't amp things up enough. The equivalent, meaning "assume I have lots of
memory and processor, just optimize for fast and not memory usage" instead
of having to increase threads, sendsize, udpsize, callbacks, etc... or fewer
switches, or persistent state based on the expected number of callbacks to
issue, etc.
Again, orthogonal.
>
> More importantly, as I amplify further in my inline comments, the
> attempt to justify reduction by reference to maintainer testing
> obligations is specious, on multiple levels.
>
> 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.
>
That's, to some degree, already true.
>
> The simple truth is, OpenAFS has a lot of developers working on features
> that need to see wider use, need to see the light of day, and need to be
> committed to the main line of OpenAFS development. The message we
> developers need to hear is that OpenAFS and its community and leadership
> are eager to incorporate as many of those features as it possibly can.
If you haven't heard it, you're not listening. That doesn't mean the
simplest way of implementing the feature is the one that should be
committed. In many cases, it actually means the opposite, since when the
next person comes along and wants to add their feature, yours should not
have precluded them from doing so.
> We don't need to hear the message that there are too many configuration
> options in OpenAFS--by all means, solve our testing problems, solve them
> PLEASE. Or appoint some of us to help solve them. But respectfully, we
> have, collectively, a right to expect the solutions to be the best
> available, to be sensible, flexible, and well reasoned.
>
> 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. That is the ecumenical spirit,
> or, if you will, the humility, that essential to our future progress as
> a community.
>
You can judge my motivations however you like.
If you remember, I wrote the original patch we're now beating the topic of
to death.
>
>
> >
> > 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.
>
> This reasoning is not cogent. 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 want to be in the position of issuing a security advisory in a few
months when moving a volume from one server to another discloses data, for
instance, because a feature in code shipping with OpenAFS, not one you
patched in, causes a volume moved from one server to another to no longer
behave in the intended manner. Just because I should be able to let you know
better doesn't mean the black eye isn't still mine in the end.
>
> >
> >> 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.
>
> I'm glad you can see your way to this. Perhaps there is an unburdensome
> way forward.
>
It still doesn't address the volume move concern. I'd hope actually to have
the volserver have some mechanism to enforce ACL semantics be identical.
You're already opening the door to recompile servers, having a new
volforward RPC which has flags to indicate what ACL bits have used for what
doesn't seem a stretch. I haven't thought this through but I bet this can
also be addressed.
>
> You have not established that requiring external patching is the only
> effective way to communicate the message
>
I don't think that was the point. The point was only that as proposed, the
extension had issues which should (could?) be a barrier to its global
adoption. Not necessarily that no proposal in this vein could be.
>
> * building OpenAFS from source carries with it acceptance of the
> responsibility for 80% of the consequences
>
disagree. see point about security advisories above.
>
> ** they may discharge an additional 15% (adding up to 115%!) of their
> responsiblity to protect users by adding "**DANGER Will Robinson!
> Danger!** to the --help output for each terrible feature like the
> proposed, which we commit into OpenAFS
>
actually, i'd suggest a switch to enable potentially hazardous features at
configure time, as a pre-requisite to the other switches working, to fulfill
this.
>
>
> > 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.
>
> The problem with this argument is that it too is uncogent. We/you/the
> gatekeepers do not carry the responsibility to test every feature
> OpenAFS can perform, but rather only a vetted list of features which we
> choose to support. This is a practical matter, a plain fact. The cause
> of honest discussion is not advanced by this silly reductio ad absurdam.
>
At this point, I disagree. It may well be that we should move to a model
where this is *stated* but at the moment it's not true.
I offer no conclusion here as I don't feel I can. We should obviously keep
discussing this.
------=_Part_46578_32965787.1228841764075
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div class="gmail_quote">On Tue, Dec 9, 2008 at 11:32 AM, Matt Benjamin <span dir="ltr"><<a href="mailto:matt@linuxbox.com">matt@linuxbox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</div>Hi Simon,<br>
<br>
In general, I am of the belief that prescriptive rules, here<br>
specifically, the proscription sites _should not have_ site local ACL<br>
bits, disregarding precedent (the entire history of AFS), should have to<br>
meet a far higher standard than 4 people on this list oppose (while at<br>
least 3 have publicly supported, and more support is, of course, out<br>
there for this feature than has weighed in.)<br>
</blockquote><div><br>Possibly also more opposition.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Rather obviously, it should take more than a simple majority of folks<br>
not seeing the purpose of some feature, when one of the largest and most<br>
significant OpenAFS deployments historically and today, worldwide, sees<br>
its merit enough to code and maintain it.<br>
<br>
To me, the discussion on principle (and the principles of sound<br>
reasoning) are what matters. I think that anyone who read Jeff<br>
Hutzelman's post should have come away with the realization that there<br>
are important matters of principle at issue here.<br>
<br>
Here is my summary, amplifying it with some more:<br>
<br>
* OpenAFS needs to stay true to its history, as well as move<br>
forward--that means it needs to take account of the needs of sites like<br>
CMU and (redacted, their preference, this is Derrick's convention of<br>
representing it)--to do otherwise is really unwise (I easily could add<br>
more adjectives here)<br>
<br>
* The argument for "uniformity" and against site-local flexibility seems<br>
to be a proxy for a much larger argument against diversity in the code<br>
base, against OpenAFS being more things to more people, where no one is<br>
harmed--the shifting of the argument to be against "too many<br>
configuration options" is the evidence for this<br>
</blockquote><div><br>The poster child for complexity is Cyrus, which was, at its inception elegant and simple. Now many people who could use its features sorely won't run it because they're scared. I don't want to chase away users. At the same time, it's important to support the things people need to do.<br>
<br>This is mostly orthogonal to the issue at hand.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Turning to that, the argument against "too many configuration switches"<br>
is rather like the argument that Mozart used "too many notes." Too many<br>
for what?</blockquote><div><br>How many are needed versus how many could be elided if we did a better job of representing what people want to do? For instance, -L was a good idea but doesn't amp things up enough. The equivalent, meaning "assume I have lots of memory and processor, just optimize for fast and not memory usage" instead of having to increase threads, sendsize, udpsize, callbacks, etc... or fewer switches, or persistent state based on the expected number of callbacks to issue, etc. <br>
<br>Again, orthogonal. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
More importantly, as I amplify further in my inline comments, the<br>
attempt to justify reduction by reference to maintainer testing<br>
obligations is specious, on multiple levels.<br>
<br>
OpenAFS gatekeepers don't need to test all the features the product can<br>
theoretically perform, they only need to test the ones that are<br>
_officially supported_. To argue otherwise is, respectfully, some type<br>
of overreaching.<br>
</blockquote><div><br>That's, to some degree, already true. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The simple truth is, OpenAFS has a lot of developers working on features<br>
that need to see wider use, need to see the light of day, and need to be<br>
committed to the main line of OpenAFS development. The message we<br>
developers need to hear is that OpenAFS and its community and leadership<br>
are eager to incorporate as many of those features as it possibly can.</blockquote><div><br>If you haven't heard it, you're not listening. That doesn't mean the simplest way of implementing the feature is the one that should be committed. In many cases, it actually means the opposite, since when the next person comes along and wants to add their feature, yours should not have precluded them from doing so.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
We don't need to hear the message that there are too many configuration<br>
options in OpenAFS--by all means, solve our testing problems, solve them<br>
PLEASE. Or appoint some of us to help solve them. But respectfully, we<br>
have, collectively, a right to expect the solutions to be the best<br>
available, to be sensible, flexible, and well reasoned.<br>
<br>
I have always assumed the fair bargain for the right to add new concepts<br>
and implementations to the system, was that I not act to _prevent<br>
others_ from adding features for which they see the need and benefit,<br>
but which I, in my ignorance, do not. That is the ecumenical spirit,<br>
or, if you will, the humility, that essential to our future progress as<br>
a community.<br>
</blockquote><div><br>You can judge my motivations however you like.<br><br>If you remember, I wrote the original patch we're now beating the topic of to death. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="Ih2E3d"><br>
><br>
> Remember, we're not just talking about different sites, but also about<br>
> potentially different semantics amongst servers at the same site. We're<br>
> also talking about a situation where the meaning of a private use value<br>
> can differ between two otherwise identical builds of the same product,<br>
> at the same site.<br>
<br>
</div>This reasoning is not cogent. It is the responsibility of site<br>
administrators (or their contractors, or whatever) to establish and<br>
maintain a uniform deployment of OpenAFS servers--or indeed, to be quite<br>
frank, their prerogative to establish and maintain whatever<br>
configuration of OpenAFS servers they darned well like.<br>
<div class="Ih2E3d"></div></blockquote><div><br>I don't want to be in the position of issuing a security advisory in a few months when moving a volume from one server to another discloses data, for instance, because a feature in code shipping with OpenAFS, not one you patched in, causes a volume moved from one server to another to no longer behave in the intended manner. Just because I should be able to let you know better doesn't mean the black eye isn't still mine in the end. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
><br>
>> which always presents these bits as ABCDEFGH, regardless of what they<br>
>> mean. If you think that's too confusing, I could certainly work up a<br>
>> proposal for protocol extensions to allow clients to discover more<br>
>> descriptive names for these bits, though I have no idea what the UI<br>
>> for 'fs sa' would look like, or what a reasonable implementation in<br>
>> OpenAFS would look like.<br>
><br>
> Such an extension would remove some of my concerns - but rather than as<br>
> an optional extra, I'd say it's pretty much essential to have it before<br>
> this kind of feature is implemented.<br>
<br>
</div>I'm glad you can see your way to this. Perhaps there is an unburdensome<br>
way forward.<br>
<div class="Ih2E3d"></div></blockquote><div><br>It still doesn't address the volume move concern. I'd hope actually to have the volserver have some mechanism to enforce ACL semantics be identical. You're already opening the door to recompile servers, having a new volforward RPC which has flags to indicate what ACL bits have used for what doesn't seem a stretch. I haven't thought this through but I bet this can also be addressed.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>You have not established that requiring external patching is the only<br>
effective way to communicate the message<br>
</blockquote><div><br>I don't think that was the point. The point was only that as proposed, the extension had issues which should (could?) be a barrier to its global adoption. Not necessarily that no proposal in this vein could be. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* building OpenAFS from source carries with it acceptance of the<br>
responsibility for 80% of the consequences<br>
</blockquote><div><br>disagree. see point about security advisories above.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
** they may discharge an additional 15% (adding up to 115%!) of their<br>
responsiblity to protect users by adding "**DANGER Will Robinson!<br>
Danger!** to the --help output for each terrible feature like the<br>
proposed, which we commit into OpenAFS<br>
<div class="Ih2E3d"></div></blockquote><div><br>actually, i'd suggest a switch to enable potentially hazardous features at configure time, as a pre-requisite to the other switches working, to fulfill this. <br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br>
> If the code is never built, how can you tell that it's still working?<br>
> I've been pushing for a while for a reduction in the number of --enable-<br>
> options, especially for little used code. If we're going to move forward<br>
> into a world where automated regression testing is the norm, this is<br>
> going to be more and more important - we simply won't be able to build,<br>
> let alone test n^2 different configuration sets.<br>
<br>
</div>The problem with this argument is that it too is uncogent. We/you/the<br>
gatekeepers do not carry the responsibility to test every feature<br>
OpenAFS can perform, but rather only a vetted list of features which we<br>
choose to support. This is a practical matter, a plain fact. The cause<br>
of honest discussion is not advanced by this silly reductio ad absurdam.<br>
<div class="Ih2E3d"></div></blockquote><div><br>At this point, I disagree. It may well be that we should move to a model where this is *stated* but at the moment it's not true.<br> <br>I offer no conclusion here as I don't feel I can. We should obviously keep discussing this.<br>
<br></div></div><br>
------=_Part_46578_32965787.1228841764075--