Limited Access Repository
I changed my repository parent so that it is not readable, not writable, not searchable by anyone except the owner, which is www-data (the user that Apache runs as) - *drwx-- 2 www-data www-data 4096 2011-07-22 15:45 /data/svn* I figure that will keep other users away from the contents. Only root and Apache can see the contents and therefore do anything with it.
Re: Subversion access control
On Thu, Jul 21, 2011 at 11:19 PM, Andy Canfield wrote: > I notice that you don't have any entries that read "... = r"; everyone who > can read can write also. No need? > Yeah, I just don't have a use case for that. The RSS feed of a repo commits from websvn is much more useful than read-only access to the server (basically websvn provides read-only access in a browser, all nice and pretty.) I'm glad you got it working! It's worth it in the end. The insurance policy that an SCM system provides is priceless.
Setuid
Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much.
Re: Subversion: existing users
On 7/22/2011 1:45 AM, Andy Canfield wrote: > >> Welcome to sys-admin hell, the "documentation is true, but not >> complete" world that I've spent so many years in. The connections >> between different pieces of information that are obvious to someone >> who's been through similar issues in the past are not obvious to a an >> intelligent but new person like yourself. > Yes. But don't forget "The documentation was true, then, but may not be > true any more". I once googled for how to install Tomcat and the first > web page I hit said that I had to recompile Apache myself. Written in 2002. The usual sysadmin rule is that if the documentation and code differ, they are both wrong. > My current impression is that the /var/syn/project/... directories need > write access to whatever system user is running the service; either > apache/mod_dav_svn.so or svnserve. Hell breaks loose when you have to > use direct access to use svnadmin. No, you either run svanamin as root and change ownership/permissions later, or su to the owning user which sometimes involves options to su to run an appropriate shell if the user in question doesn't have one for direct logins. > Since websvn is said to work, and > websvn runs under Apache, it should be happy with the same system user > ownership as apache/mod_dav_svn.so likes. Websvn, viewvc, etc., generally only need read access. > Obviously a server tends to have lots of different users, doing lots of > different things. A centralized login authentication system is > desirable. And for my experience, on a single machine server, that's the > standard OS user login. It works for ssh and sftp and ftp. No need to > memorize three passwords, no need to set up three different > authentication files. I think you've typed a lot more already without accomplishing this than it would have taken to create the separate passwd file with three users that either svnserve or apache need for their simple form of authentication. > Unfortunately http and MySQL don't authenticate that way, so we have to > set up parallel systems. 'htpasswd' is just another version of > '/etc/passwd' to me, and a usually unnecessary redundancy. There are a couple of catches. One is that the system passwords in /etc/shadow are only readable by root - intentionally to prevent password-cracking programs from easily breaking the encryption. Giving other programs access opens an assortment of potential vulnerabilities. Another is that it only solves the problem when you only have one machine and you want all involved parties to have access to everything. This is rarely the case as you start adding network services. > I look at setting up Subversion authentication, and the first option I > hope for is: > use-what-you-already-have = yes If what you already have is LDAP, you probably can. There are ways to make apache work with the system passwd/shadow files but I'm not sure what the best approach currently is. Mod_auth_pam used to work but I don't think distributions include it now and you have to give apache read access to /etc/shadow to use it with the system files. > Of course, my experience is in small groups, not big ones. For example, > it has been decades since I've worked with a project involving more than > one programmer. That's why I have to LEARN Subversion; because I've > never needed it before and I"m not even sure that I need it now. But it > sounds like a useful skill. Large groups will likely already have some network authentication mechanism set up (and really large groups will have a different set of people managing it...). Apache has a large set of authentication mechanisms/modules so you can probably make it work with whatever you need. However, even large groups often use outside contractors for development work and there may be times when you want to control access separately for subversion or certain other services. -- Les Mikesell lesmikes...@gmail.com
Re: Setuid
On 7/22/2011 8:38 AM, Andy Canfield wrote: Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much. It prevents privately owned and managed repositories. Normally, individual users can set up their own repositories for their own (personal) projects or files. If you are planning to do this on a server that you wish to lock down, then I see no reason why it would cause problems, but if users can login and do other work on this machine, you are constraining them. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: Can I prevent a file from being modified?
On Thu, Jul 21, 2011 at 12:47 PM, Andreas Krey wrote: > On Thu, 21 Jul 2011 11:06:00 +, David Weintraub wrote: >> I have a pre-commit hook that allows you to set a directory as >> "add-only". This was mainly for the tags directory. You can create a >> tag, but once created, it can't be modified. > > The devil's advocate wants to know it this script accidentally also > allows adding new files/directories *within* a tag; thus getting > interesting results when accidentally executing > > svn cp $base/trunk $base/tags/blub -m "$message" It all depends how you configure the control file. If you simply did something like this: file = /tags/** user = @ALL access = add-only Then, it would be possible for someone to add a directory inside another directory under the tags directory. I haven't worried about this. My main concern isn't someone doing something malicious, but doing something more human. For example, a developer did a "svn switch" to a tag to see the files on a particular revision, then promptly forgot they did the switch and edit that working directory. No clue would be given that they were not on trunk or a branch while doing their work, and they may simply not realize it even after a commit. However, if you want to prevent maliciousness, you first lock down the directories under tags: [FILE No modifying anything under /tags] file = /tags/** user = @ALL access = read-only This prevents any changes at all under the /tags directory. Now, you add in the following: [FILE Allow users to add new tags, but that's all] file = /tags/* user = @ALL access = add-only This allows you to add in directories directly under the "tags" directory via an "svn cp", but you can't add anything under those directories. I don't make a distinction between files, and directories. It is possible to use "svn add" to add in empty directories and files directly under the /tags directory, so it's not entirely secure from maliciousness. However, it really wouldn't do anything more than be annoying and since this is version control, the culprit could easily be caught. -- David Weintraub qazw...@gmail.com
Re: Can I prevent a file from being modified?
On 7/22/2011 11:36 AM, David Weintraub wrote: This allows you to add in directories directly under the "tags" directory via an "svn cp", but you can't add anything under those directories. I don't make a distinction between files, and directories. It is possible to use "svn add" to add in empty directories and files directly under the /tags directory, so it's not entirely secure from maliciousness. However, it really wouldn't do anything more than be annoying and since this is version control, the culprit could easily be caught. Yes, the revision control part is always there. While we tend to use tags to get simple human-generated, human-readable names for specific revisions (through the convention of never committing changes there), all you really have to do to be sure you have a particular version is use the path@revision syntax in your workflow. It is impossible for that to ever be changed through subversion client operations. -- Les Mikesell lesmikes...@gmail.com
Re: Setuid
On 7/22/2011 10:38 AM, Andy Canfield wrote: If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. You don't need suid for this. There are normally shell scripts that start system services that are executed as root and can change their uid before starting the program. Apache is an exception because it typically has to open port 80 for listening and ports below 1024 are restricted to root in unix-like systems - so it has to start as root and change its own uid after opening the socket. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. I wouldn't do that without auditing the code. If there are any paths of execution that can delete or modify files, making it suid gives any local user the ability to delete/modify your repositories and anything else owned by apache. Normally, the point of running a network service with authentication is to prevent most users from having direct access to the files under control. Plus, users may want to have their own private subversion repositories that they create with svnadmin and use file:// access in svn. -- Les Mikesell lesmikes...@gmail.com
Re: Setuid
On Fri, Jul 22, 2011 at 11:38 AM, Andy Canfield wrote: > Had what seems to be a bright idea. It is a bright idea for a Subversion > server on Linux or OS X; AFAIK this idea has no relevance to Windows: > > Take note of the user and group that Apache runs as. Call this combination > APACHE, meaning APACHE_USER and APACHE_GROUP. > > Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever > WebSVN does to any repository will be done by APACHE. > > If I set the svnserve program to be owned by APACHE, and setuid and setgid, > then whatever svnserve does to any repository will also be done by APACHE. > Only root, or the APACHE user, can make this change to the svnserve program > binary. Sounds dangerous and untested. svnserve, for example, is not designed to be run suid. It's not necessarily handling UID versus EUID correctly for this. (It might, it's not tested.) It's much more common to turn it around. If you want a shared svn://, svn+ssh://, and http:// access to the same repository, run a secondary Apache daemon as the alternative "svn" user. I've done so to keep Apache access separate from svn access quite successfully. Run it on another port to avoid conflicts with the primary Apache server, store logs in a distinct location in the config files, use a proxy on the main server to pass requests for https://sitename/svn/ to the https://sitename:8443/svn/, or a similar ProxyPass setup, and it helps you run multiple services safely on the same server. > If I set the svnadmin program to be owned by APACHE, and setuid and setgid, > then whatever svnadmin does to any repository will also be done by APACHE. > > If I set the svnlook program to be owned by APACHE, and setuid and setgid, > then whatever svnlook does to any repository will be done by APACHE. > > So the three access paths - http:, svn:, and direct - will all operate using > the same user and group. > > You don't want to do this to any program, such as 'svn', which relies on > user authentication, since it needs to know the actual user that is running > the program. But any program which operates directly on the repository can > be set this way and that ensures that the repository is always manipulated, > at a low level, by the same user all the time. > > So a post-installation setup would include: > sudo bash > cd /usr/bin > chown APACHE_USER svnadmin svnlook svnserve > chgrp APACHE_GROUP svnadmin svnlook svnserve > > This idea also allows me to make the the respository itself accessable only > by APACHE. This ensures that the repository can only be manipulated by > Subversion code itself (or by root): > sudo bash > mkdir /var/svn > chown APACHE_USER /var/svn > chgrp APACHE_GROUP /var/svn > chmod 0700 /var/svn > > If I also do this: > sudo bash > rm /usr/bin/svnadmin > then all repository creation would have to be done via something like > WebSVN, which I assume requires authentication. > > How does that sound to you guys? Where are the flaws in this idea? > > Thank you very much. > >
404 on SQLite dependency in get-deps.sh
Problem: The URL used by get-deps.sh from subversion-1.6.17.tar.gz to get SQLite, http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz, is 404. Proposed Solution: It looks like sqlite.org has changed (?) their filename format, as the latest version of the amalgamation file is 3.7.7.1, and the URL is: http://sqlite.org/sqlite-amalgamation-3070701.zip Need to change: Line 31: SQLITE_VERSION=3.7.5 to SQLITE_VERSION=3070701 Line 53: wget -nc http://www.sqlite.org/$SQLITE.tar.gz to wget -nc http://www.sqlite.org/$SQLITE.zip Line 61: gzip -dc $TEMPDIR/$SQLITE.tar.gz | tar -xf - to unzip $TEMPDIR/$SQLITE.zip Line 67: mv sqlite-$SQLITE_VERSION sqlite-amalgamation to mv $SQLITE.zip sqlite-amalgamation -Conor
Need for a local Subversion server?
I have a question regarding the need of a subversion mirror server. Our work is done on UNIX systems. We currently have a master repository in England. We mirror it as a read only repository to the states. The system that acts as the Subversion server in the states is rather old and its faster to do checkouts from the remote repository then the local one. I’m curious why we even need a local subversion server. We cannot add anything to the local repository. Developers check out the code, update the files in their working directory, then commit them to the remote server. Now trying to commit, resolve conflicts, and merges are another matter. Latency has a far greater impact on those tasks. We often thought about making a post-hook on the commit to initiate syncs from the master to the remote site in order to do the conflict resolution locally, allowing our developers to use a GUI interface or type in their xterm and not wait for the characters to appear. We have yet to do that test to see if it would help. (We did try the WanDisco Enterprise solution and like it, but in a spending freeze so absolutely no funds for that product) I do appreciate your time and any constructive responses. :) phil
Re: Need for a local Subversion server?
On Fri, Jul 22, 2011 at 10:12:31AM -0700, Phil Montgomery wrote: > I have a question regarding the need of a subversion mirror server. > > Our work is done on UNIX systems. We currently have a master repository in > England. We mirror it as a read only repository to the states. The system > that acts as the Subversion server in the states is rather old and its > faster to do checkouts from the remote repository then the local one. I?m > curious why we even need a local subversion server. We cannot add anything > to the local repository. Developers check out the code, update the files in > their working directory, then commit them to the remote server. > > > Now trying to commit, resolve conflicts, and merges are another matter. > Latency has a far greater impact on those tasks. We often thought about > making a post-hook on the commit to initiate syncs from the master to the > remote site in order to do the conflict resolution locally, allowing our > developers to use a GUI interface or type in their xterm and not wait for > the characters to appear. We have yet to do that test to see if it would > help. Have you considered using a write-through proxy setup? See http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html > (We did try the WanDisco Enterprise solution and like it, but in a spending > freeze so absolutely no funds for that product) The write-though proxy feature that ships with Subversion provides similar advantages. The only major difference is that write operations are proxied through to the master server, and must be copied back to the slave server. So there is a time window where the slave isn't up-to-date. It still provides major advantages for read-only operations, and this speeds up lots of things, including merges. Basically, anything but commit operations can be answered from the local server so there is little latency. The subversion project itself uses this type of setup with the Apache Software Foundation's Subversion server, where our own code is hosted. There is one server in the US (which acts as the master server) and one in Europe (which acts as the slave). svn.apache.org resolves to a different address depending on location.
Re: Need for a local Subversion server?
On 7/22/2011 12:12 PM, Phil Montgomery wrote: I have a question regarding the need of a subversion mirror server. Our work is done on UNIX systems. We currently have a master repository in England. We mirror it as a read only repository to the states. The system that acts as the Subversion server in the states is rather old and its faster to do checkouts from the remote repository then the local one. I’m curious why we even need a local subversion server. We cannot add anything to the local repository. Developers check out the code, update the files in their working directory, then commit them to the remote server. Now trying to commit, resolve conflicts, and merges are another matter. Latency has a far greater impact on those tasks. We often thought about making a post-hook on the commit to initiate syncs from the master to the remote site in order to do the conflict resolution locally, allowing our developers to use a GUI interface or type in their xterm and not wait for the characters to appear. We have yet to do that test to see if it would help. We have some cases of (very) remote teams working out of the main repository and some where the live project repository is near the remote group and svnsync is used to pull a copy back to headquarters for a backup and some of the builds. The tradeoffs are fairly obvious but the remote repository was set up when network connectivity was not very good - I'm not sure we'd do it again under better conditions. I'm kind of curious about how git-svn would work out for this kind of use. -- Les Mikesell lesmikes...@gmail.com
Re: 404 on SQLite dependency in get-deps.sh
The following changes will be included in the next release: * r1134734 Fix sqlite-amalgamation location and archive format. Branch: 1.6.x-r1134734 Justification: Users report get-deps.sh of sqlite is currently broken. Notes: r1134734 also bumped dependency versions; the backport branch excludes those bumps. Votes: +1: danielsh, arfrever, julianfoad Without looking into the details, I guess you're reporting the same issue? Conor wrote on Fri, Jul 22, 2011 at 11:37:25 -0400: > Problem: > > The URL used by get-deps.sh from subversion-1.6.17.tar.gz to get SQLite, > http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz, is 404. > > Proposed Solution: > > It looks like sqlite.org has changed (?) their filename format, as the > latest version of the amalgamation file is 3.7.7.1, and the URL is: > http://sqlite.org/sqlite-amalgamation-3070701.zip > > Need to change: > Line 31: SQLITE_VERSION=3.7.5 to SQLITE_VERSION=3070701 > Line 53: wget -nc http://www.sqlite.org/$SQLITE.tar.gz to wget -nc > http://www.sqlite.org/$SQLITE.zip > Line 61: gzip -dc $TEMPDIR/$SQLITE.tar.gz | tar -xf - to unzip > $TEMPDIR/$SQLITE.zip > Line 67: mv sqlite-$SQLITE_VERSION sqlite-amalgamation to mv > $SQLITE.zip sqlite-amalgamation > > > -Conor
differencing only header files
Is there an easy way to restrict svn diff operation to files of a certain extension (say .h)? A quick glance at the manual suggested nothing to me.
Re: Need for a local Subversion server?
On Fri, 22 Jul 2011 13:01:06 +, Les Mikesell wrote: ... > I'm kind of curious about how git-svn would work out for this kind of use. I'd say that pretty much depends on your round-trip time. The initial 'git svn clone' can take seriously long; I did one for a repo that yields 328 commits in 450 seconds, over a consumer DSL line (via http portforwarded via ssh). The regular operations will take about as long as ther native svn counterparts, except that you can batch commits. Also, one can prepare the git-svn clone once (and possibly while being colocated with the server), and use it as a template instead of doing additional full 'git svn clone's. In the 450 seconds there were a few occurrences of a trunk directory appearing and vanishing within tags, but otherwise the roundtrip time was the limiting factor, not the bandwidth. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: 404 on SQLite dependency in get-deps.sh
Looks like the same issue, thanks for the response. I tried to search for this at http://subversion.apache.org/issue-tracker.html, but came up empty. -Conorr On Fri, Jul 22, 2011 at 2:10 PM, Daniel Shahaf wrote: > The following changes will be included in the next release: > > * r1134734 > Fix sqlite-amalgamation location and archive format. > Branch: > 1.6.x-r1134734 > Justification: > Users report get-deps.sh of sqlite is currently broken. > Notes: > r1134734 also bumped dependency versions; the backport branch excludes > those bumps. > Votes: > +1: danielsh, arfrever, julianfoad > > Without looking into the details, I guess you're reporting the same > issue? > > Conor wrote on Fri, Jul 22, 2011 at 11:37:25 -0400: > > Problem: > > > > The URL used by get-deps.sh from subversion-1.6.17.tar.gz to get SQLite, > > http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz, is 404. > > > > Proposed Solution: > > > > It looks like sqlite.org has changed (?) their filename format, as the > > latest version of the amalgamation file is 3.7.7.1, and the URL is: > > http://sqlite.org/sqlite-amalgamation-3070701.zip > > > > Need to change: > > Line 31: SQLITE_VERSION=3.7.5 to SQLITE_VERSION=3070701 > > Line 53: wget -nc http://www.sqlite.org/$SQLITE.tar.gz to wget > -nc > > http://www.sqlite.org/$SQLITE.zip > > Line 61: gzip -dc $TEMPDIR/$SQLITE.tar.gz | tar -xf - to unzip > > $TEMPDIR/$SQLITE.zip > > Line 67: mv sqlite-$SQLITE_VERSION sqlite-amalgamation to mv > > $SQLITE.zip sqlite-amalgamation > > > > > > -Conor >
Re: differencing only header files
On Fri, Jul 22, 2011 at 4:01 PM, Steve Cohen wrote: > Is there an easy way to restrict svn diff operation to files of a certain > extension (say .h)? A quick glance at the manual suggested nothing to me. Nope: you'd have to parse the output of a "list" command or a local "find", which shouldn't be hard. find . -name .svn -type d -prune -o -type f -name \*\.h -print | sort Should give you a good list on a Linux or UNIX box should give you a handy alphabetical list to work with
Re: differencing only header files
On Fri, 22 Jul 2011 15:01:09 -0500 Steve Cohen wrote: > Is there an easy way to restrict svn diff operation to files of a > certain extension (say .h)? A quick glance at the manual suggested > nothing to me. > A hacky way would be to use something like: $ ack -g '\.h$' | xargs -d '\n' svn diff Here it does this: < shlomif[fcs]:$trunk/fc-solve/source$ ack -g '\.h$' | xargs -d '\n' svn diff Index: scans.h === --- scans.h (revision 3977) +++ scans.h (working copy) @@ -72,3 +72,4 @@ #endif #endif /* FC_SOLVE__SCANS_H */ +hello svn: 'prefix.h' is not under version control shlomif[fcs]:$trunk/fc-solve/source$ For information about ack, see: http://betterthangrep.com/ As you can see, it warns because it finds non-versioned files. This can be dealt with using: $ ack -g '\.h$' | (while read T; do (svn info "$T" > /dev/null 2>&1) && echo "$T" ; done) | xargs -d '\n' svn diff Alternatively, you can use the Subversion APIs (or one of their higher language bindings) to write a custom diff command. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/ Chuck Norris is the greatest man in history. He killed all the great men who could ever pose a competition. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: Setuid
On 07/22/2011 11:29 PM, David Chapman wrote: On 7/22/2011 8:38 AM, Andy Canfield wrote: Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much. It prevents privately owned and managed repositories. Normally, individual users can set up their own repositories for their own (personal) projects or files. If you are planning to do this on a server that you wish to lock down, then I see no reason why it would cause problems, but if users can login and do other work on this machine, you are constraining them. Ah, I see a lack of terminology here. Consider the respository located at /var/svn/sample, the repository named "sample" and accessed through the browser as "http://example.com/svn/sample";. What is the name for "/var/svn"? Is it a "Repository Collection"? The config entry is "SVNParentPath", so let's call it the "SVNParent". If you have an account on that server computer, and you don't have root access, and you want your own pesonal repository collection, then even today you can't use http: access to it, either because you can't configure Apache or because Apache is already configured for the standard SVNParent. The suggestion would make the SVNParent accessable only through the standard software, never directly. Any user could create his own respository, but it would be in the standard SVNParent. If /usr/bin/svnserve is owned by www-data (APACHE) and setuid, then you can't run /usr/bin/svnserve to access your own personal SVNParent. It can access your own repository in the standard SVNParent, but not your own SVNParent. However, it appears that it can be done using two Linux commands: *copy /usr/bin/svnserve ~/bin/svnserve copy /usr/bin/svnadmin ~/bin/svnadmin* The copies are owned by you and are no longer setuid. So you can run ~/bin/svnserve and it will operate under your user name and manage your own personal SVNParent. (I have not tested this yet, but it "should work"). On Fri, 22 Jul 2011 13:24:55 -0400 Nico Kadel-Garcia wrote: Sounds dangerous and untested. svnserve, for example, is not designed to be run suid. It's not necessarily handling UID versus EUID correctly for this. (It might, it's not tested.) That sounds like a serious concern; no way to be sure. But for me it would be worth the experiment.
