Lieven -
Appreciate the example. From reading it, can I assume the system admins
set the permissions by hand-editing the authz file?
Best Regards,
Ed Bosco.
-----Original Message-----
From: Lieven Govaerts [mailto:lgo@mobsol.be]
Sent: Friday, May 19, 2006 10:48 AM
To: 'Jeb'
Cc: 'B. Smith-Mannschott'; users@subversion.tigris.org
Subject: RE: authz: what has precidence when user is multiply referenced
for a particular path?
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" <benpsm@gmail.com>
<mailto: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_tes
ts.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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 22 22:19:12 2006