[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: authz: what has precidence when user is multiply referenced for a particular path?

From: Jeb <jeb.beasley_at_penske.com>
Date: 2006-05-22 12:40:33 CEST

Steven Simpson wrote:

>Frank Gruman wrote:
>>Steven Simpson wrote:
>>>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
>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.
@security_programmer = rw
@developers= -r -w

@security_programmer = rw
@developers= rw
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.
Received on Mon May 22 12:42:11 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.