From the users mailing list - there are quite a number of opinions on this
Following is excerpt from two of the more relevant messages
-------- Original Message --------
Subject: Re: authz: what has precidence when user is multiply
referenced for a particular path?
Date: Fri, 19 May 2006 07:55:23 -0400
From: Jeb <jeb.beasley@penske.com>
To: Lieven Govaerts <lgo@mobsol.be>
CC: B. Smith-Mannschott <benpsm@gmail.com>, users@subversion.tigris.org
References:
<c76b69900605190229y79fed74dv626832d8f1470c9@mail.gmail.com>
<1148038369.446dace13077e@webmail.mobsol.be>
Lieven,
I think that is contrary to most interpretations of best practice for
security models. Most severe restriction should apply. This is the way
most OSs and Databases interpret multiple access rights paths. I
realise they probably did this for efficiency, but I feel it should be
changed to act on the most restrictive.
Jeb Beasley
Lieven Govaerts wrote:
>Quoting "B. Smith-Mannschott" <benpsm@gmail.com>:
>
>
>
>>Respectfully, no, ... it isn't.
>>
>>[paint:/projects/paint]
>>@paint-developers = rw
>>jane = r
>>
>>Since "jane" is also a member of paint-developers, does she have
>>read-only or read-write permssion? Which takes precidence? The more
>>permissive? The more restrictive? The first? The last? This should
>>be clarified.
>>
>>
>
>Hi Ben,
>
>I think you're right in that it should be clarified.
>
>If you like to have more detailed information on some topics, you can look at
>the python tests of authorization. They're not complete yet, but we're working
>on that:
>http://svn.collab.net/repos/svn/trunk/subversion/tests/cmdline/authz_tests.py
>
>To answer your specific question, I found that once you grant the user a right
>(@paint-developers=rw), you can't remove that right on the next line(jane=r).
>In fact, subversion just parses the first line, sees that you jane has rw
>rights through the paint-developers group and just stops parsing.
>
>Hope this helps,
>
>Lieven.
>
>
>
>
>
>
> -------- Original Message --------
> Subject: Re: authz: what has precidence when user is multiply
> referenced for a particular path?
> Date: Mon, 22 May 2006 06:40:33 -0400
> From: Jeb <jeb.beasley@penske.com>
> To: Steven Simpson <ss@domain.invalid>
> CC: users@subversion.tigris.org
> References: <ajdr621h5c8f09c64e20fhb3jsl99vtl2v@4ax.com>
> <20060519143531.3577E22007A@assei1bl6.telenet-ops.be>
> <4dmr621lj0naf8b8n2l0bd8nbuhuqajo4e@4ax.com>
> <446E11B3.3070709@domain.invalid> <446FFCC6.8070905@verizon.net>
> <447069D4.2040601@domain.invalid>
>
>
> 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 Tue May 23 13:11:26 2006