On Thu, Jan 20, 2011 at 10:41 AM, Jan Keirse <jan.keirse_at_tvh.be> wrote:
> David Aldrich <David.Aldrich_at_EU.NEC.COM> schreef op 20/01/2011 10:24:28:
>
>> Hi Jan
>>
>> > I've changed my mind, there is something that may be better than
>> > externals, although it requires a little trick.
>> > You should be able to create a commit hook that checks if the authz
> file
>> > reflects the restrictions you want on a specific folder
>> > (*/thesecretfolder/*) for the branch
>> > (/branches/somebranch/thesecretfolder) and if not add the
> restrictions.
>>
>> I get your drift but may I check I am understanding you correctly?
>>
>> The authz file would contain:
>>
>> */thesecretfolder/*
>> @privileged_group = rw
>> * =
>>
>> svn does not expand wildcards in authz but I guess it will not
>> complain about such an entry. The hook reads authz and does the
>> comparison of the actual commit path against this wildcard path
>> using regular expressions (or whatever). Am I right so far?
>
> No, that would not stop read access. What I wanted to say is that if you
> commit a file a commit hook checks if it's path indicates it should be
> mentioned in the authz file (because for example the path contains a
> foldername thesecretfolder) and if it finds such folder and does not find
> an entry for it in authz file it adds the folder to the authz file.
> If a developer branches trunk to branches/myexperiment the commit hook
> will fire and detect the new branch and adjust permissions to the secret
> folder in the authz file. (add /branches/myexperiment/thesecretfolder.)
> This would avoid accidents. The only thing it would not catch is if a
> developer deliberately branches /trunk/yourproject/yoursecretfolder to
> /branches/makethesecretpublic, but off course if you don't trust your
> developers not to do that you'd better not give them access to the code in
> the first place because there would be smarter ways to deliberately
> publish a company secret (methods that are not so easy to track back to
> the offender.)
>
>>
>> The hook must then check that the committer has rights to commit to
>> that path. So the hook uses the access permission specification in
>> the above entry, and checks that the committer belongs to
>> 'privileged_group'. Then the hook allows or blocks the commit. Am I
> correct?
>
> As said above that would stop commits but not checkout. I don't think
> there's a pre-checkout hook.
>
>> > The advantage of this approach over externals is that you'll have
> atomic
>> > commits, the version of the 'secretfolder' will be linked to the
> versions
>> > in the rest of the repository,... And if one day the suggested
> wildcard
>> > feature is implemented all you'll have to do is update the authz file
> to
>> > contain a wildcard, remove the commit hook and you're done.
>>
>> Yes, I like your idea, thanks. I am quite opposed to using externals
>> for this since I realised that externals are not well supported in
>> branching and merging.
>>
>> I did think of another approach before receiving your suggestion. I
>> thought of having a proprietary 'my_authz' file which allows
>> wildcards. Then our own mangler would check what branches exist,
>> read our my_authz and generate a real authz file with all the
>> necessary expanded paths and permissions. Could be run regularly by
>> cron (or whatever).
>
> My suggestion is basically doing this but not with cron, but in the commit
> hook. If you do it with cron you'd have a small window where the data
> would be public.
>
>> However, your suggestion is more elegant. Not sure which would be
>> more efficient.
If someone decides to put a lot of effort in this for a custom
solution, you may want to consider another option: to take a good look
at issue http://subversion.tigris.org/issues/show_bug.cgi?id=2662
(authz with wildcards), and try to bring it home.
This feature is not impossible, it's just that someone has to take the
time to drive it to completion. Read up on the issue and the comments
that are listed therein, and take a look at the patches that have been
proposed. Maybe someone can take a fresh look at those patches, clean
them up, and start a discussion on the dev-list to get the thing
reviewed in detail, and maybe added to svn core ...
(I am not hindered by any detailed knowledge about this issue, just
thinking in general terms here)
Cheers,
--
Johan
Received on 2011-01-20 13:41:48 CET