[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Confining hook execution

From: Sergey A. Lipnevich <sergeyli_at_pisem.net>
Date: 2002-08-08 04:02:24 CEST

Hi All,

I have a practical question regarding deployment of Subversion. Faced
with hosting several repositories which shouldn't see each other, I'm
thinking of how to make each repository more isolated and the whole box
more secure. Here are two choices:
a) Wait until perchild MPM stabilizes (an hour ago, it was still broken,
just tried building again, from the start get a lot of errors "[emerg]
(13)Permission denied: apr_proc_mutex_lock failed. Attempting to
shutdown process gracefully." and the same for ..._unlock), and run each
repository under separate user id;
b) Use good old prefork MPM, allow mod_dav_svn run (over SSL, hopefully
using certificates for authentication, which are on the way according to
the latest developments -- I should study these as a book), but try to
confine all hooks in the jail;
c) Combine perchild MPM and hook chroot-ing if/when possible.

Why am I afraid of my own hook scripts? Because I'd like to allow over
people modify these files in the repository, and deploy new hook scripts
on commit or on schedule. Even if I don't deploy after each commit, I'm
still faced with auditing hooks for security, so jailing them sounds
like a more time-effective solution. I'm aiming among other things at a
modified commit notification which would allow every authenticated
developer to register for commit mail in any part of the repository
tree, however stupid that may sound :-), practically by modifying some
parameters file right in the repository. Then, in commit hook, I'd read
such file in each directory, build a "notification tree", and them mail
away.

So, using b) as a short-term solution, may I ask you if it's a totally
bad idea to add chroot-ing hooks, and how would one approach
implementing it?
Thank you!

--Sergey.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 04:03:09 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.