You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Edward Diener <ed...@loyaltyworks.com> on 2004/09/03 20:01:49 UTC
Controlling update and/or commit access to a repository URL
I could not find information on ways in which an administrator can control
access to directories in a repository on a user by user basis. By access I
mean the ability to allow or prevent a given user from checking out,
updating, and/or committing changes to a repository. Does SVN have any
notion of this built into the repository filesystem on a directory by
directory basis ? If not, are there any plans to add this to SVN to make it
easy for an administrator to allow or deny repository clients to
access/update or commit repository data ?
The company for which I work wants to set up a repository whereby certain
clients can checkout/update and/or commit data to certain repository URL
paths while others can not. This seems a pretty standard and easy way to me
to control repository access. Yet I could not find any administrator command
that would allow me to do such a thing depending on the user and the
repository path.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Edward Diener <ed...@tropicsoft.com>.
Ben Collins-Sussman wrote:
> On Sat, 2004-09-04 at 06:03, Edward Diener wrote:
>
>> Wouldn't it be better if per-user access to a specific repository
>> path were built into SVN itself ?
>
> Yes, it would be nice to have real ACLs directly in the repository.
> We plan to do that someday.
>
> For now, various forms of access control can be done via svnserve,
> apache, or hook scripts.
Thanks for your response. Good luck in implementing ACL-like repository
access in the future as I look forward to it when it appears.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2004-09-04 at 06:03, Edward Diener wrote:
> Wouldn't it be better if per-user access to a specific repository path were
> built into SVN itself ?
Yes, it would be nice to have real ACLs directly in the repository. We
plan to do that someday.
For now, various forms of access control can be done via svnserve,
apache, or hook scripts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Edward Diener <ed...@tropicsoft.com>.
Nathan Kidd wrote:
> Lee Merrill wrote:
>
>> Well, I fished a bit, and svnserve can do per-user permissions:
>>
>> http://svnbook.red-bean.com/svnbook/ch06s03.html#svn-ch-6-sect-3.2.1
>>
>> But not per-directory permissions. But still a hook script could
>> restrict commits on a per-directory basis, and the svnserve
>> permissions could do the per-user read access for you. So I think it
>> can be done (though I'm new to all this, and may have missed a beat
>> somewhere).
>
> In fact, the svn tarball already contains two different hook scripts
> to do exactly this! (take your pick of perl or python). Look in the
> tools/hook-scripts subdir.
>
> I use svnperms.py in my pre-commit hook to easily enforce who can add,
> remove and update, and where. It's so flexible (yes, regexes) that
> you can say user-so-and-so can add new tags under /tags/ but not add
> under, /tags/*/ (I.e. could create /tags/v1.4/ but not mess up
> /tags/v1.3 by adding /tags/v1.3/newdir/).
>
> Since these scripts are a pre-commit business you're still stuck with
> per-user granularity to control read access.
Wouldn't it be better if per-user access to a specific repository path were
built into SVN itself ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Nathan Kidd <na...@hummingbird.com>.
Lee Merrill wrote:
> Well, I fished a bit, and svnserve can do per-user permissions:
>
> http://svnbook.red-bean.com/svnbook/ch06s03.html#svn-ch-6-sect-3.2.1
>
> But not per-directory permissions. But still a hook script could
> restrict commits on a per-directory basis, and the svnserve permissions
> could do the per-user read access for you. So I think it can be done
> (though I'm new to all this, and may have missed a beat somewhere).
In fact, the svn tarball already contains two different hook scripts to
do exactly this! (take your pick of perl or python). Look in the
tools/hook-scripts subdir.
I use svnperms.py in my pre-commit hook to easily enforce who can add,
remove and update, and where. It's so flexible (yes, regexes) that you
can say user-so-and-so can add new tags under /tags/ but not add under,
/tags/*/ (I.e. could create /tags/v1.4/ but not mess up /tags/v1.3 by
adding /tags/v1.3/newdir/).
Since these scripts are a pre-commit business you're still stuck with
per-user granularity to control read access.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Lee Merrill <Le...@bustech.com>.
Hi Edward,
Well, I fished a bit, and svnserve can do per-user permissions:
http://svnbook.red-bean.com/svnbook/ch06s03.html#svn-ch-6-sect-3.2.1
But not per-directory permissions. But still a hook script could
restrict commits on a per-directory basis, and the svnserve permissions
could do the per-user read access for you. So I think it can be done
(though I'm new to all this, and may have missed a beat somewhere).
Lee
--
+=========================================================
+ Lee Merrill lee@bustech.com 919-866-2008
+=========================================================
Unless otherwise stated, any views presented in this email are solely those of the author and do not necessarily represent those of the company.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Edward Diener <ed...@loyaltyworks.com>.
"Lee Merrill" <Le...@bustech.com> wrote in message
news:4138D03F.7060304@bustech.com...
> Hi Edward,
>
> Yes, you can do this, though it's not built into the repository, it
> can be done in the web server, see this link for more information:
>
> http://svnbook.red-bean.com/svnbook/ch06s04.html#svn-ch-6-sect-4.4
This requires Apache. Unfortunately we are currently using svn server. I
will have to convince my company to use Apache for SVN in order to provide
this functionality.
>
> It could also be done via a start-commit hook script, to check the
> user and the directories being modified, to see if they are authorized
> to make those changes:
>
> http://svnbook.red-bean.com/svnbook/ch05s02.html#svn-ch-5-sect-2.1
This looks better when if Apache is not being used, but does not allow me to
protect a user from read access to a repository.
While both are viable possibilities has there really been no impetus from
users of SVN to have SVN provide this feature itself. Clearly svn client
could theoretically be updated to accept 'include' or 'exclude' lists of
usernames for each of its repository directories and/or permissions for each
user, to be administered through an administrator via some sort of protected
server side files. This would put access control in the hands of svn itself.
Has this been a topic which others have discussed or requested for future
versions of SVN at all ? It does seem that within any SCCS system that the
system itself should provide easy functionality for restricting or allowing
access to directories/files within it. Perhaps the answer to that from SVN
has always been, use Apache it's free. But that does not make configuring
such functionality as easy as it could be made from within svn itself
through its own internal mechanisms. I am thinking of the fact that if some
sort of configuration existed on the SVN server for allowing or restricting
access, then the svn client command could easily access this information and
allow or deny users the ability to carry out access to certain directories
in a repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Controlling update and/or commit access to a repository URL
Posted by Kevin Bentley <ke...@gmail.com>.
> ps. i was actually referring to multiple copies of httpd2.x running at the
> same time...
This is possible, I just did it last night. If you are running under
UNIX, just run configure --prefix=/usr/local/apache2_alt (and all the
other options you want), then again with a different directory, of
course running make; make install, etc. between running configure.
Now you will have two independent apache installations that can have
different modules, etc. If you can use two IP addresses on your
server, you can just bind each apache installation to a different IP,
otherwise, you can use a port other than 80 for the alternate
instance.
If you're running under Windows, it's a bit of a pain to rebuild the
Apache source with a different prefix, but it is possible.
If you need more help with that, feel free to email me off-list and
I'll try to help you.
Kevin Bentley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn design/usage issue...
Posted by kf...@collab.net.
Peter Valdemar Mørch <sw...@sneakemail.com> writes:
> First off, please start a new thread by creating a new message to the
> list, and not by replying to an old message. When you "Reply", your
> email headers contain a line like this:
> > In-Reply-To: <10...@localhost.localdomain>
> So threaded mail readers will present them as part of an existing
> thread (under the one where Message-ID is equal to the string
> above). That lowers your chances of somebody replying to you.
Amen to that. By the way, this is
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
(in case people want a convenient way to say the same thing in the
future).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn design/usage issue...
Posted by Peter Valdemar Mørch <sw...@sneakemail.com>.
Hi Bruce,
First off, please start a new thread by creating a new message to the
list, and not by replying to an old message. When you "Reply", your
email headers contain a line like this:
> In-Reply-To: <10...@localhost.localdomain>
So threaded mail readers will present them as part of an existing thread
(under the one where Message-ID is equal to the string above). That
lowers your chances of somebody replying to you.
bruce bedouglas-at-earthlink.net |Lists| wrote:
> the issue that i'm looking at has to do with the underlying working copies.
> if i create the user access information on the server, the user then uses a
> svn client to access the repository. on the client side, the user would
> create a working dir/copy area. the user would then be able to
> checkout/modify the files from the dirs that he has access to. this process
> should allow the user to be able to access files from multiple dirs, and to
> be able to check the files back in without accessing files in other areas.
>
> have i missed anything...
No, that sounds right. Access to these local copies is determined by
standard operating system access rights. After check-out, these working
copies are just regular files. Any apache/mod_svn access rights will not
be honored at this point.
> i envision 400-500 separate dirs for the various apps.
Fine.
> i'm also going to
> have to periodically copy the different versions (once an app works!) into a
> separate 'tag' dir.
I recommend not doing a file-system copy (/bin/cp) but a copy in the
repository (svn cp). See the svn book about tags.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svn design/usage issue...
Posted by bruce <be...@earthlink.net>.
hi...
i'm strongly considering using svn.. and i'd like to get some
opinions/comments...
i'm considering an environment, where each function in an app will be
completely separate. i want to restrict the users working on the app to the
given function(s) that they have been assigned. as i understand svn, i
can/should be able to use apache/svn/mod_dav_svn and create a kind of
directory level access process, that will allow me to have users log into
svn, and restrict the dirs that the user has access to.
so far, so good.
the issue that i'm looking at has to do with the underlying working copies.
if i create the user access information on the server, the user then uses a
svn client to access the repository. on the client side, the user would
create a working dir/copy area. the user would then be able to
checkout/modify the files from the dirs that he has access to. this process
should allow the user to be able to access files from multiple dirs, and to
be able to check the files back in without accessing files in other areas.
have i missed anything...
i envision 400-500 separate dirs for the various apps. i'm also going to
have to periodically copy the different versions (once an app works!) into a
separate 'tag' dir.
comments/feedback/thoughts welcomed...
thanks...
-bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Controlling update and/or commit access to a repository URL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-09-03 at 16:13, bruce wrote:
> so, kindly stop with the assumptions. i'm willing to believe that you
> probably get plenty of people who don't read, but simply fire off questions.
> but that's not the case here...
Sorry, don't mean to offend. But every question you've asked is
discussed directly in chapter 6: the existence of the mod_authz_svn
module; the syntax of the text-file is uses to control access policy;
how to create a general apache user-database; and so on. Your
questions give the *appearance* of someone who hasn't read the book. We
get lots of those folks in IRC. ;-)
> peace!
peace.
>
> ps. i was actually referring to multiple copies of httpd2.x running at the
> same time...
Why would you want to do that? Apache already spins off dozens of
children to serve requests.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Controlling update and/or commit access to a repository URL
Posted by bruce <be...@earthlink.net>.
ben...
i have read the book... numerous times... (athough i didn't get the feeling
that the dav_mod) would do what you're saying it does.. in fact i'd reread
it now, if my browser wasn't screwing up...
so, kindly stop with the assumptions. i'm willing to believe that you
probably get plenty of people who don't read, but simply fire off questions.
but that's not the case here...
you know what happens to people who assume (ass-u-me)!!!!
peace!
ps. i was actually referring to multiple copies of httpd2.x running at the
same time...
thanks!!
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Friday, September 03, 2004 2:04 PM
To: bedouglas@earthlink.net
Cc: 'Lee Merrill'; users@subversion.tigris.org
Subject: RE: Controlling update and/or commit access to a repository URL
On Fri, 2004-09-03 at 15:52, bruce wrote:
> cool....
>
> thanks for the update... but i have a question.. how does one run multiple
> versions of the httpd process simultaneously on the same server...????
You mean, run apache1.3 and apache2.0 side-by-side?
FAQ: http://subversion.tigris.org/project_faq.html#multiple-apachim
> i do have one question though regarding the
> file that you specify. is it a standard text file, that contains
> user:password pairs, and is the password plain text, or is the password
> encrypted (md5)...
Yes, it's a text file, in INI format, more or less. I'm not going to
sit here and re-read the book to you. Please stop wondering about what
you can and cannot do, or how things work. All you need to do is read
chapter 6, honest!
http://svnbook.red-bean.com/svnbook/ch06.html
If you have specific questions *after* reading this stuff, we're happy
to clarify.
---------------------------------------------------------------------
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: Controlling update and/or commit access to a repository URL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-09-03 at 15:52, bruce wrote:
> cool....
>
> thanks for the update... but i have a question.. how does one run multiple
> versions of the httpd process simultaneously on the same server...????
You mean, run apache1.3 and apache2.0 side-by-side?
FAQ: http://subversion.tigris.org/project_faq.html#multiple-apachim
> i do have one question though regarding the
> file that you specify. is it a standard text file, that contains
> user:password pairs, and is the password plain text, or is the password
> encrypted (md5)...
Yes, it's a text file, in INI format, more or less. I'm not going to
sit here and re-read the book to you. Please stop wondering about what
you can and cannot do, or how things work. All you need to do is read
chapter 6, honest!
http://svnbook.red-bean.com/svnbook/ch06.html
If you have specific questions *after* reading this stuff, we're happy
to clarify.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Controlling update and/or commit access to a repository URL
Posted by bruce <be...@earthlink.net>.
cool....
thanks for the update... but i have a question.. how does one run multiple
versions of the httpd process simultaneously on the same server...????
this would definitely solve my issue!!!!!!
i'm asusming that the external 'dat' file that you state is reparsed on
every http connection is easily structured in a manner that allows me to
specify a given repository directory, and to specify the user/group that has
access to that given directory. i do have one question though regarding the
file that you specify. is it a standard text file, that contains
user:password pairs, and is the password plain text, or is the password
encrypted (md5)....
thanks...
-bruce
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Friday, September 03, 2004 1:39 PM
To: bedouglas@earthlink.net
Cc: 'Lee Merrill'; users@subversion.tigris.org
Subject: RE: Controlling update and/or commit access to a repository URL
On Fri, 2004-09-03 at 15:32, bruce wrote:
> if you want to restrict a user from being
> able to access a given directory within a repository, the only way you can
> really do this through svn is via the apache setup.
Correct, you must use apache.
> the issue with this is
> that if you want to dynamically modify the users, and the given
> dirs/permissions that the users will have with respect to the dirs, you're
> going to have to modify the httpd.conf file on a continual basis, which is
> going to require restarting the apache server....
Incorrect. Use mod_authz_svn. Read chapter 6. It's exactly for this
purpose: controlling read/write access to specific directories by
specific users and groups. No apache restarts required. Everything is
defined in a single file that is re-parsed on every new HTTP connection.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Controlling update and/or commit access to a repository URL
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-09-03 at 15:32, bruce wrote:
> if you want to restrict a user from being
> able to access a given directory within a repository, the only way you can
> really do this through svn is via the apache setup.
Correct, you must use apache.
> the issue with this is
> that if you want to dynamically modify the users, and the given
> dirs/permissions that the users will have with respect to the dirs, you're
> going to have to modify the httpd.conf file on a continual basis, which is
> going to require restarting the apache server....
Incorrect. Use mod_authz_svn. Read chapter 6. It's exactly for this
purpose: controlling read/write access to specific directories by
specific users and groups. No apache restarts required. Everything is
defined in a single file that is re-parsed on every new HTTP connection.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Controlling update and/or commit access to a repository URL
Posted by bruce <be...@earthlink.net>.
yeah...
but the start_commit hook only works (as i understand it) when you're doing
the commit back to the repository. if you want to restrict a user from being
able to access a given directory within a repository, the only way you can
really do this through svn is via the apache setup. the issue with this is
that if you want to dynamically modify the users, and the given
dirs/permissions that the users will have with respect to the dirs, you're
going to have to modify the httpd.conf file on a continual basis, which is
going to require restarting the apache server....
so, if i correctly understand what the poster wants to do, the start_commit
hook won't give him what he wants...
svn does not at this time, appear to give you a way to dynamically restrict
the user on a per dir basis, so that users can't access the dir at all...
-bruce
-----Original Message-----
From: Lee Merrill [mailto:LeeMerrill@bustech.com]
Sent: Friday, September 03, 2004 1:13 PM
Cc: users@subversion.tigris.org
Subject: Re: Controlling update and/or commit access to a repository URL
Hi Edward,
Yes, you can do this, though it's not built into the repository, it
can be done in the web server, see this link for more information:
http://svnbook.red-bean.com/svnbook/ch06s04.html#svn-ch-6-sect-4.4
It could also be done via a start-commit hook script, to check the
user and the directories being modified, to see if they are authorized
to make those changes:
http://svnbook.red-bean.com/svnbook/ch05s02.html#svn-ch-5-sect-2.1
Lee
>I could not find information on ways in which an administrator can control
>access to directories in a repository on a user by user basis. By access I
>mean the ability to allow or prevent a given user from checking out,
>updating, and/or committing changes to a repository. Does SVN have any
>notion of this built into the repository filesystem on a directory by
>directory basis ? If not, are there any plans to add this to SVN to make it
>easy for an administrator to allow or deny repository clients to
>access/update or commit repository data ?
>
>
>
>
--
+=========================================================
+ Lee Merrill lee@bustech.com 919-866-2008
+=========================================================
Unless otherwise stated, any views presented in this email are solely those
of the author and do not necessarily represent those of the company.
---------------------------------------------------------------------
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: Controlling update and/or commit access to a repository URL
Posted by Lee Merrill <Le...@bustech.com>.
Hi Edward,
Yes, you can do this, though it's not built into the repository, it
can be done in the web server, see this link for more information:
http://svnbook.red-bean.com/svnbook/ch06s04.html#svn-ch-6-sect-4.4
It could also be done via a start-commit hook script, to check the
user and the directories being modified, to see if they are authorized
to make those changes:
http://svnbook.red-bean.com/svnbook/ch05s02.html#svn-ch-5-sect-2.1
Lee
>I could not find information on ways in which an administrator can control
>access to directories in a repository on a user by user basis. By access I
>mean the ability to allow or prevent a given user from checking out,
>updating, and/or committing changes to a repository. Does SVN have any
>notion of this built into the repository filesystem on a directory by
>directory basis ? If not, are there any plans to add this to SVN to make it
>easy for an administrator to allow or deny repository clients to
>access/update or commit repository data ?
>
>
>
>
--
+=========================================================
+ Lee Merrill lee@bustech.com 919-866-2008
+=========================================================
Unless otherwise stated, any views presented in this email are solely those of the author and do not necessarily represent those of the company.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org