Claudio Ochoa wrote:
> Is there any way to differentiate between system and non-system users,
> in order to grant read-write and read-only access to them, respectively?
As of today you can hack what you want into svnserve, using pre-commit
and pre-revprop-change hooks. The commit author can be looked up in the
transaction via svnlook. You can therefore look the name up, either in
the svn passwd store or the system store, to decide in which category
the user is in, and appropriately deny access at that level.
Soon, this should also be possible at a finer grained level, because of
the addition of path-based access control support to svnserve, which
would allow you to define a group of system users and a group of svn
users (listed in the svn passwd file) and attribute different access
credentials to each group.
Also, on a side note, I'm a little perplexed about why you want to
restrict write access to only one of the two repository access methods.
What is the rationale behind that? Off the top of my head, I can see
one reason you might want to do this, which relies on some inaccurate
assumptions. My anticipated apologies for my jumping to wrong
conclusions if you are motivated by something completely and utterly
different, in which case I'd be interested to hear about it.
The base I'm thinking of is "Writing should go over ssh for added
security". This argument is essentially moot, because the changes are
still leaked in cleartext over the network by someone updating their
working copy via svn://. Also, the password is not sent in plaintext
via svn://, contrary to somewhat of a popular belief. So, if you're
offering svn:// access anyway, there is no real advantage to also having
svn+ssh://, except for the alternate authentication possibilities
brought on by PAM, which you don't seem to really be using here.
Some hosting providers offering subversion repositories (eg. BerliOS
developer) put up both svn and svn+ssh access methods, but have a
different reasoning as far as I understand:
- their svn access is completely read only, and is aimed for anonymous
tracking of the repository.
- their svn+ssh access is used for authenticated commits, because
(a) it allows them to use things like pam_*sql or pam_ldap and store
users/projects in more maleable data stores than flat files, and
(b) it is "user-interface" consistent with cvs+ssh, which is the
only way I know to commit without leaking passwords in cleartext with a
stock CVS. This helps people ease themselves into "that new cvs thingy"
with minimum transition pains. Essentially, a historical reason.
Sorry for all this extra text, I felt like ranting a little :-). Feel
free to ignore any or all of this if you don't really care.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 23 12:28:02 2005