Hi all,
Why would user1 need to "own" file1 or why would group1 need to "own" file1
inside the svn repository? Where is the benefit to that? What's the purpose?
Why not have the VC tool (the gatekeeper of the repository) grant needed access
to file1 (or files or modules) as appropriate to authenticated users?
If access in a subversion repository needs to be broken down to a lower level,
couldn't subversion itself (maybe via a svnadmin command) create subversion
"access groups" for accounts in subversion, then have properties to allow
and/or deny permission to read and/or write based on the svn "access group" one
is in. Maybe:
svn:group_write (co and ci)
svn:group_read (co only)
svn:group_noaccess (neither co nor ci, can't even look at)
As a CM admin, I would like to be able to manage access/usage levels in the
repositories I administer myself (after the users are properly authenticated, I
want to separate authentication process with what a user can do inside the svn
repo once authenticated and granted access to svn), not to have to rely on
sysadmins or others to ensure the proper users are added (_and_ removed) from
the groups in a timely manor.
So if svn:group means you need to be a member of the OS group to do something
with it in svn, as a CM admin, that (group membership) is not in my control,
and as a SVN lurker, I hope it is not implemented that way. (currently I use
pserver with non-root account and readers/writers file, being able to manage
access control at a lower level would be great)
Thanks. Hopefully something I said will be relevant.
Mark
--- Justin Erenkrantz <jerenkrantz@apache.org> wrote:
> On Wed, Aug 21, 2002 at 05:13:33PM +0200, Branko ??ibej wrote:
> > Well, the first thought and concern is that this is extremely
> > Unix-centric -- but I guess you're aware of that. :-) The second thing
> > that comes to mind is that, to make this complete, you'd have to store
> > the file's owner and/or group, too.
>
> That could be added via svn:owner, svn:group. In my case, I wouldn't
> want that as the owner or group may change, but I want the
> permissions to be the same.
>
> > All of which leads towards storing and restoring ACLs.
>
> Exactly. I believe that this can become a feature of the SCM rather
> than something it ignores.
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 00:46:27 2002