You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "B. Smith-Mannschott" <be...@gmail.com> on 2006/05/19 09:29:01 UTC
authz: what has precidence when user is multiply referenced for a particular path?
Re: authz: what has precidence when user is multiply referenced for a
particular path?
Posted by Frank Gruman <fg...@verizon.net>.
<snip>
>
>
> 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..
>
</snip>
Actually - the default security is to deny all unless you do something
like *=r. This is not a mandatory value so you could very easily
restrict everyone and then only perform grants.
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for
a particular path?
Posted by Jeb <je...@penske.com>.
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
>
>
>
Re: authz: what has precidence when user is multiply referenced for
a particular path?
Posted by Steven Simpson <ss...@domain.invalid>.
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.)
* 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
--
ss at comp dot lancs dot ac dot uk |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for a
particular path?
Posted by Frank Gruman <fg...@verizon.net>.
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.
[groups]
developers = me, you, them, others
[/repo]
*=r
@developers=rw
For many open source products, this is a standard configuration. Let
anyone read the source. But not everyone should be able to commit
directly to the repository. Based on your statement, no one would ever
be able to write to this repository. And please don't point me to the
<Limit> directives in Apache. First, because not everyone uses it, and
second, because I would much rather have all of my user control in one
location than spread out through multiple other places.
[groups]
developers = me, you, them, others
[/repo]
*=r
@developers=rw
others=r
This scenario as I explained in an earlier thread would allow me to
create my groups as I would normally do and assign permissions to users
in the order listed. The last set permission should win. In my above
example, the "others" user does not have write permission to THIS
repository but may have it on others. There are some folks who use this
system with 50 or more developers. They would ideally create their core
groups and create assignments off of those groups. But what if I have a
junior programmer who just joined a group? Sure - add the developer to
the group and then take away the permission from the "sensitive"
products until they have learned all they need.
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for
a particular path?
Posted by Steven Simpson <ss...@domain.invalid>.
Greg Thomas wrote:
> On Fri, 19 May 2006 16:31:39 +0200, "Lieven Govaerts" <lg...@mobsol.be>
> wrote:
>
>>> From: Greg Thomas [mailto:thomasgd@omc.bt.co.uk]
>>>
>>> This makes it impossible to give anonymous read only access,
>>> a very desirable feature:
>>>
>>> [/foo]
>>> *=r
>>> @developers=rw
>>>
>> That's not correct!
>>
>> First of all, in your example Subversion will behave like this:
>> 1. if you need read access: the first line applies, so it grants you read
>> access
>> 2. if you need write access: it skips the first line, and grants you access
>> based on the second line of you're in the developer group.
>>
> Oops, good point! More coffee needed ...
>
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.
--
ss at comp dot lancs dot ac dot uk |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: RE: Re: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Fri, 19 May 2006 16:31:39 +0200, "Lieven Govaerts" <lg...@mobsol.be>
wrote:
>> From: Greg Thomas [mailto:thomasgd@omc.bt.co.uk]
>>
>> This makes it impossible to give anonymous read only access,
>> a very desirable feature:
>>
>> [/foo]
>> *=r
>> @developers=rw
>
>That's not correct!
>
>First of all, in your example Subversion will behave like this:
>1. if you need read access: the first line applies, so it grants you read
>access
>2. if you need write access: it skips the first line, and grants you access
>based on the second line of you're in the developer group.
Oops, good point! More coffee needed ...
>Beside, in your apache configuration ...
Remember that svnserve also supports authz configuration, now.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Perceval BRET <br...@gmail.com>.
imho, the system should continue parsing and finally keep the less
restrictive access for the user.
Perceval
2006/5/19, Frank Gruman <fg...@verizon.net>:
>
> Greg Thomas wrote:
> On Fri, 19 May 2006 07:55:23 -0400, Jeb <je...@penske.com>
> wrote:
>
>
>
> I think that is contrary to most interpretations of best practice for
> security models. Most severe restriction should apply.
>
> This makes it impossible to give anonymous read only access, a very
> desirable feature:
>
> [/foo]
> *=r
> @developers=rw
>
> Greg
>
> So then why can't we let the system continue parsing the permissions? An
> earlier post (from Lieven) stated
>
>
> "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."
>
>
>
>
> [/foo]
> *=r
> @developers=rw
> jane=r
>
>
> If this is done, then the order in which the permissions are assigned takes
> significance. So read-only can be given to everyone, the developers group
> could be given full rw access, Jane is part of the developers group, but not
> for this particular repository so she should be read-only.
>
> my 2 cents(USD).
>
> Regards,
> Frank
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for a
particular path?
Posted by Frank Gruman <fg...@verizon.net>.
Greg Thomas wrote:
> On Fri, 19 May 2006 07:55:23 -0400, Jeb <je...@penske.com>
> wrote:
>
>
>> I think that is contrary to most interpretations of best practice for
>> security models. Most severe restriction should apply.
>>
>
> This makes it impossible to give anonymous read only access, a very
> desirable feature:
>
> [/foo]
> *=r
> @developers=rw
>
> Greg
>
So then why can't we let the system continue parsing the permissions?
An earlier post (from Lieven) stated
"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."
[/foo]
*=r
@developers=rw
jane=r
If this is done, then the order in which the permissions are assigned
takes significance. So read-only can be given to everyone, the
developers group could be given full rw access, Jane is part of the
developers group, but not for this particular repository so she should
be read-only.
my 2 cents(USD).
Regards,
Frank
RE: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Lieven Govaerts <lg...@mobsol.be>.
Frank,
> -----Original Message-----
> From: Frank Gruman [mailto:fgatwork@verizon.net]
> Sent: vrijdag 19 mei 2006 16:44
> >
> >
> You are working under the assumption that he uses http://. I
> myself do, but I still see many others out there who use
> svn:// access. Which is trying to read only the
> authorization file.
The first part of my mail is applicable to both mod_authz_svn and svnserve.
I showed also how to achieve the solution for Greg's problem with
mod_authz_svn. You can achieve the same thing with svnserve when specifying
the 'anon-access = read' option in svnserve.conf
>And I am confused by what you just
> stated. You said that it "skips" the first line for read
> access and grants access based on the second line. Does that
> mean that it does parse the first line or does not??
Yes it does, sorry for the bad wording. In fact, svn will ask the authz
subsystem if a user has read or write access on a certain folder in the
repository. The authz system will then start parsing sections
([A001:/branches/DEV_...]) until it finds one that matches the folder. Then
it will parse all lines in the section, until it finds one that grants the
user the requested access (ie. read or write). Simply said, with each line
you can add extra rights for users, but you can't take them away.
> This leads back to my previous post where I think _EVERY_ row
> in the group should get parsed, and the order in which they
> are entered is the order of precedence. So you could grant
> access to everyone and take away from the one or two that
> don't need it or any other of the massive number of
> permission scenarios we run into.
And at first sight I agree with you, although I'm not aware now of the
consequences. As I said in my other email, I'm not aware of the reasons why
people have implemented it the way it is now, maybe they had some very valid
reasons besides performance to do it this way.
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for a
particular path?
Posted by Frank Gruman <fg...@verizon.net>.
Lieven Govaerts wrote:
>> -----Original Message-----
>> From: Greg Thomas [mailto:thomasgd@omc.bt.co.uk]
>>
>> This makes it impossible to give anonymous read only access,
>> a very desirable feature:
>>
>> [/foo]
>> *=r
>> @developers=rw
>>
>
> That's not correct!
>
> First of all, in your example Subversion will behave like this:
> 1. if you need read access: the first line applies, so it grants you read
> access
> 2. if you need write access: it skips the first line, and grants you access
> based on the second line of you're in the developer group.
>
> Beside, in your apache configuration you can put these lines to achieve the
> same thing:
> ...
> # allow read-only access to all users in the AD server
> <Limit GET PROPFIND OPTIONS REPORT>
> Satisfy Any
> </Limit>
>
> Require valid-user
> ...
>
> Lieven.
>
>
You are working under the assumption that he uses http://. I myself do,
but I still see many others out there who use svn:// access. Which is
trying to read only the authorization file. And I am confused by what
you just stated. You said that it "skips" the first line for read
access and grants access based on the second line. Does that mean that
it does parse the first line or does not??
This leads back to my previous post where I think _EVERY_ row in the
group should get parsed, and the order in which they are entered is the
order of precedence. So you could grant access to everyone and take
away from the one or two that don't need it or any other of the massive
number of permission scenarios we run into.
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Lieven Govaerts <lg...@mobsol.be>.
> -----Original Message-----
> From: Greg Thomas [mailto:thomasgd@omc.bt.co.uk]
>
> This makes it impossible to give anonymous read only access,
> a very desirable feature:
>
> [/foo]
> *=r
> @developers=rw
That's not correct!
First of all, in your example Subversion will behave like this:
1. if you need read access: the first line applies, so it grants you read
access
2. if you need write access: it skips the first line, and grants you access
based on the second line of you're in the developer group.
Beside, in your apache configuration you can put these lines to achieve the
same thing:
...
# allow read-only access to all users in the AD server
<Limit GET PROPFIND OPTIONS REPORT>
Satisfy Any
</Limit>
Require valid-user
...
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Fri, 19 May 2006 07:55:23 -0400, Jeb <je...@penske.com>
wrote:
>I think that is contrary to most interpretations of best practice for
>security models. Most severe restriction should apply.
This makes it impossible to give anonymous read only access, a very
desirable feature:
[/foo]
*=r
@developers=rw
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Lieven Govaerts <lg...@mobsol.be>.
Jeb,
I agree with your statement, in fact I was surprised as well when I found
out this behaviour. If you want to know more about this please start a
thread on the dev list, I wasn't involved in the original requirements
gathering nor design process.
Where I work we use another model for managing authorization, which makes
that I never encountered this behaviour before. We're currently managing 75
applications(repositories) with over 350 developers/engineers using
Subversion. Each of these applications has it's own section, like this:
# section for app A001
a001_dev = account1, account2, account3
a001_relco = account1
a001_bugfix = account3
a001_admin = @a001_relco
...
# end of section for app A001
# everyone in our department has read access
* = r
# branch configuration for app A001
[A001:/branches/DEV_V0001.00.00]
@a001_dev = rw
[A001:/branches/HF_V0001.00.01]
@a001_bugfix = rw
@a001_relco = rw
...
So we have 5 different roles that people can be in a project. We have global
read-only authorization, and then for each application and types of branches
we specify which groups/roles have write access. We'll never grant access
rights to individual users, we only use groups! While we do the actual
configuration of the authz file, it's up to the teams to decide which
persons play which roles. We found that this is the best way to keep the
authorization manageable.
hope this helps,
Lieven.
________________________________
From: Jeb [mailto:jeb.beasley@penske.com]
Sent: vrijdag 19 mei 2006 13:55
To: Lieven Govaerts
Cc: B. Smith-Mannschott; users@subversion.tigris.org
Subject: Re: authz: what has precidence when user is multiply
referenced for a particular path?
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" <be...@gmail.com>
<ma...@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.p
y
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.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging
Program.
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@subversion.tigris.org
For additional commands, e-mail:
users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: authz: what has precidence when user is multiply referenced for
a particular path?
Posted by Jeb <je...@penske.com>.
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" <be...@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.
>
>
>
>----------------------------------------------------------------
>This message was sent using IMP, the Internet Messaging Program.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
Re: authz: what has precidence when user is multiply referenced for a particular path?
Posted by Lieven Govaerts <lg...@mobsol.be>.
Quoting "B. Smith-Mannschott" <be...@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.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org