Branko Cibej wrote:
> Julian Foad wrote:
> > On Thu, 2009-10-01 at 19:16 +0200, Branko Cibej wrote:
> >> Seriously: don't try to overload path-based authz [...]
> >
> > Thanks... but please read the rest of the thread first :-) I'm not.
> Well yes; i did read it. Part of the differenceis the "repos-level" vs.
> "filesystem-level", and with obliterate, you're deep in the latter.
> Sooner or later.
I really appreciate your feedback. And yes you're right that I'll be
deep in the FS in the end, as my impression is that the space-saving
aspect of obliterate is the more important aspect for the majority of
users (users meaning administrators).
> > But even after reading what I'm thinking about, you may think it's not
> > something I should even think about. Why am I thinking like this?
> > Because I see a similarity between authz and the data-hiding requirement
> > which is a necessary semantic part of "obliterate". I think it is worth
> > examining this similarity to learn something from it, even though the
> > obvious (and almost vertainly best) implementation is to actually remove
> > stuff from the FS rather than introduce a special "hiding" layer.
>
> There are similarities ... I can see two:
>
> * The concept of hiding something from clients.
> * The pain that happens to clients' existing working copies when you
> hide or unhide something.
>
> There are also differences:
>
> * Authz is (currently) time-irrelevant; your proposed obliterate
> works on specific revisions.
> * Obliterate doesn't care who's looking at the tree; authz does.
Yup, two clear differences.
> * Authz is (currenty, brokenly :) a RA-layer-specific optional
> feature; obliterate cannot be.
That's not a conceptual difference. Authz is RA-layer-specific just a
de-facto outcome of how authz was developed. A comparable situation with
obliterate is that it could be FS-type-specific - implemented for FSFS
but not BDB or vice versa, and at least it will necessarily have
different supporting implementations for the two FS types.
Of course users will want obliterate to be available on both FSFS and
BDB, and as developers we will want the design and implementation to be
as FS-agnostic as possible, but it will certainly be dependent on if and
when we implement equivalent things in two back-ends.
> Last but not least: Data hiding is only one aspect of obliterate. Wait
> one moment while I move these sheep's entrails to grab my crystal ball
> ... ah. It says here that once you start on the space-saving and/or
> data-erasing aspect, you'll want the FS-level data hiding anyway as
> twiddling txns is unavoidable.
Maybe. I think what you're getting at is that data-hiding at the repos
layer, with data-destruction going on underneath it at the FS layer, is
not a clean design because the two layers would have to synchronize
their knowledge of what's hidden. If they didn't, the repos layer might
expose paths that have been destroyed at the FS layer. Or that sort of
thing: a spurious coupling between the layers.
> Also, as far as I can remember, our authz isn't really very good at
> hiding paths. ISTR issues about that, e.g., that when you have no access
> to A/X, you can still see X in A, though not its contents.
Sure. That doesn't particularly bother me for obliterate purposes.
> So it appears that if you piggy-back "hiding obliterate" onto the authz
> layer, you may first have to fix the authz layer, and then later do all
> the FS-related work anyway. Low-hanging fruit may on occasion turn out
> to be overripe durian, but de gustibus non disputandum est.
Don't know about having to "fix the authz layer". Is it the case that
the RA-layer-specific nature of authz is ingrained so that the authz
callbacks would not even be invoked in RA-local if RA-local provided
implementations of them?
Thanks again. And yes I basically agree that this isn't the way to go,
but still think it's important to understand it.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402671
Received on 2009-10-01 22:08:11 CEST