Steven Simpson wrote:
>Frank Gruman wrote:
>
>
>>Steven Simpson wrote:
>>
>>
>>><snip>
>>>No, I think you were right, in the context that was snipped: "Most
>>>severe restrictions should apply" (Jeb). In that case, whoever you are,
>>>both lines apply, and the most severe restriction is to take away 'w',
>>>whether you're in @developers or not.
>>>
>>>
>>>
>>>
>>I disagree with that. What you just said completely removes the
>>ability to set a repository as world readable and group/individual
>>writable.
>>
>>
>Yes, I agree. I'm not advocating Jeb's suggestion, merely pointing out
>that someone else, who also thought it was bad, had interpreted it
>correctly, after being told otherwise. Here's a summary of how this
>particular branch of the argument developed (as I understand it, of course):
>
> * Lieven Govaerts said that svn stops as soon as it finds sufficient
> permissions within the directory entry.
> * Jeb then said that svn's behaviour was unconventional, and
> suggested that the rule should be "most severe restrictions should
> apply". (I don't think he was saying how svn currently works.)
>
>
True, I am not describing current svn behavior, but that of most other
security and legal systems with which I am familiar. To satisfy the
anonymous read facility the *=r should be treated as a privelege
"grant," not a restriction. @developers = rw, would grant read and
write access to developers. If necessary to deny a member of developers
from reading some sensitive code it would be possible to set up
something like.
[secure_code]
@security_programmer = rw
@developers= -r -w
[unsecure_code]
@security_programmer = rw
@developers= rw
*=r
security_programmer should be given most of the same rights as
developers, but they should not be member of developers else they lose
their access to [secure_code] (Using the proposed deny wins metaphor.)
The default security would be no access unless someone provides * = rw
or otherwise grants access on project levels. It seems the current
default security is wide open..
> * Greg Thomas said that Jeb's suggested behaviour would prevent a
> certain useful configuration.
> * Lieven told Greg that the configuration was still possible (but I
> think that Lieven hadn't realised that Greg was talking about the
> suggested behaviour, or perhaps that the suggested and actual
> behaviours were different - correct?).
> * Greg seemed to agree that he'd made a mistake, and that Lieven's
> interpretation was correct.
> * I assured Greg that his original assessment was correct - the
> suggested behaviour would prevent a useful configuration.
>
>Cheers,
>
>Steven
>
>
>
Received on Mon May 22 12:42:11 2006