Re: Blocking root from SVN repository
On Thu, Aug 28, 2014 at 3:28 AM, Zé jose.pas...@gmx.com wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? There is no file server. This discussion is about local repositories on a local system (a workstation) managed and accessed by a single user. And yet, the there was the problem of accessing through the file system under different user ids. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. This is the problem. I doubt anyone who claims this is a reasonable approach has even considered the problem and thought about how the solution is simply unacceptable. On the contrary, everyone arguing for using a server feels that filesystem protections are inadequate. If you don't care about that, there is nothing inherent to subversion that makes file:// access a problem. For example, picture the scenario where someone tries to pitch subversion to a version control newbie to use for such basic tasks such as track changes to a file tree present on his file system: newbie: this version tracking thing sounds neat. how do I track this folder, then? svn supporter: well, you start off by installing Apache and mod_dav_svn on your desktop, register a dedicated user account to run the server, and setup a subversion server. Don't forget to read these books on the basics behind server management, or else you risk getting hit by a myriad of security problems... For someone already using apache, that's trivial - just module that can co-exist with a myriad of others. And if you aren't using apache, svnserve is easy. And all are packaged such that anyone familiar with the the operating system or installing any program can do it easily. More to the point, in any organization, only one person has to set up the server and a large number of people only need the client. Do you believe this is acceptable? Even plain old rsync -a is a far better alternative than this. If you just want a backup copies of a few versions taken at random points in time, there are lots of better solutions (I like backuppc myself) but they all involve getting those copies onto a different filesystem and stored such that the same hardware or software error or user command that destroys the original won't take the backups with it. Frankly, this approach makes no sense. It makes much more sense and much more efficient to simply abandon subversion and migrate to pretty much any version control system. I'm not aware of any other system who forces users to install, manage and run servers just to track changes made to a file. How is this acceptable? Using file:// is no worse than any other mechanism that stores the data so any user can corrupt it directly - but no better either. If that's what you want, subversion will let you do it. However, it is designed to do better and let you put your files under central control with better management than the local filesystem can provide. You just have to decide what you want from it. And you are right that some of the version control systems designed for distributed use might be better suited to having multiple copies sitting around in different places in different states like you have to do if you just have files with some backup copies somewhere - and you are willing to lose versions if you have a problem with your local copy. Subversion's strength is in keeping one authoritative copy in a place where it can be managed better than client's own filesystems. -- Les Mikesell lesmikes...@gmail.com
Re: Blocking root from SVN repository
On 08/27/2014 05:09 PM, jbl...@icloud.com wrote: On Aug 27, 2014, at 8:28 AM, Zé jose.pas...@gmx.com wrote: Additionally, to those security-concious people, installing servers on your workstation just to access local repositories isn't exactly on the top of best practices. Don't you agree? Not at all. Running a server which only answers to calls via the loopback interface (or local-domain sockets) is quite common. In fact, look at your machine's own process list. You will find a large number of helper processes that run with UIDs other than as root. Those processes tend to be configured by people who had to invest significant amounts of time and effort to know what they were doing. I don't believe this should not be expected, let alone required, from end-users who only wish to get a basic tool to perform a basic task. In fact, I'm not aware of a single version control system which forces that on anyone who only wishes to, say, keep track of the changes applied to a directory tree. The point of separating your repository access to a server process allows you to insulate file access permissions to one UID separate from your own (priviledge separation). If all users on a single box access the repository through this server process, you create a layer of abstraction and prevent file ownership/permissions flipping and actually _increase_ security and preserve the integrity of your repo. My point is that in a significant number of cases, all users on a single box means a singleuser on a single box, who already has complete access to the repo files. It makes no sense to argue for these hurdles if they actually don't accomplish nothing. This means that all the requirements to learn and waste time configuring and managing servers aren't justified. Meanwhile, there are plenty of version control systems out there that don't impose any of these requirements. Zé
Re: Blocking root from SVN repository
On 08/27/2014 05:58 PM, Bob Archer wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? There is no file server. This discussion is about local repositories on a local system (a workstation) managed and accessed by a single user. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. This is the problem. I doubt anyone who claims this is a reasonable approach has even considered the problem and thought about how the solution is simply unacceptable. For example, picture the scenario where someone tries to pitch subversion to a version control newbie to use for such basic tasks such as track changes to a file tree present on his file system: newbie: this version tracking thing sounds neat. how do I track this folder, then? svn supporter: well, you start off by installing Apache and mod_dav_svn on your desktop, register a dedicated user account to run the server, and setup a subversion server. Don't forget to read these books on the basics behind server management, or else you risk getting hit by a myriad of security problems... Do you believe this is acceptable? Even plain old rsync -a is a far better alternative than this. Frankly, this approach makes no sense. It makes much more sense and much more efficient to simply abandon subversion and migrate to pretty much any version control system. I'm not aware of any other system who forces users to install, manage and run servers just to track changes made to a file. How is this acceptable? Zé
Re: Blocking root from SVN repository
On Thu, Aug 28, 2014 at 4:28 AM, Zé jose.pas...@gmx.com wrote: On 08/27/2014 05:58 PM, Bob Archer wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? There is no file server. This discussion is about local repositories on a local system (a workstation) managed and accessed by a single user. Bob was referring to the host with the SVN repository on it. Calling it a file server was confusing, but accidental. Stay calm, please. It's also not accessed by a single user. In UNIX permission terms, it's being accessed by your personal account, one user, and as you described it, root, another user. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. This is the problem. I doubt anyone who claims this is a reasonable approach has even considered the problem and thought about how the solution is simply unacceptable. And I'll tried to explain that you can use 'svn+ssh' to channel the access to a designated user, whether your own account or a designated 'svn'' user. By controlling the relevant SSH keys, you can set it up to not require passwords for your SSH keys, and to have the SSH key enforce svn-only access for that particular application. Most of us already have an SSH daemon running, and it doesn't need a background svnserve daemon running. The svnserve runs only when started by, and is open only during, that particular SSH session to that particular SSH connection. The alternative, which will usually work, is to set up group memberships and use 'sgid' permissions judiciously in the Subversion repository. Such permissions are not replicated by 'svnsync' or other back and restoration approaches, so it's extra work. Mind you, for local config file management and no need for centralizing the content elsewhere, I tend to use RCS for individual files (mostly because I'm old, and it's familiar.), or git for directories. That way the repo is entirely local to the working directory, and I'm less likely to have the kind of issue you're having right now. For example, picture the scenario where someone tries to pitch subversion to a version control newbie to use for such basic tasks such as track changes to a file tree present on his file system: newbie: this version tracking thing sounds neat. how do I track this folder, then? svn supporter: well, you start off by installing Apache and mod_dav_svn on your desktop, register a dedicated user account to run the server, and setup a subversion server. Don't forget to read these books on the basics behind server management, or else you risk getting hit by a myriad of security problems... Subversion is evolved from CVS. CVS basically had the same issues about permissions: locall file based access was possible, but could create permissions issues when multiple users wrote to it directly. And you're talking about multiple users: your personal account, and root. Subversion is better than CVS in every way, for many reasons. And the svnserve daemon is not Apache, it's built into every published Subversion distribution I've seen, and I've explained twice now that svn+ssh is built into the system and doesn't require running a separate daemon. Do you believe this is acceptable? Even plain old rsync -a is a far better alternative than this. Oh, lordie. You're comparing apples and oranges, and getting mad because you might have to peel the orange to use it. And oh, by the way? If you feel the need for rsync based backups, do look into 'rsnapshot' as an effective toolkit to manage rsync backups. Frankly, this approach makes no sense. It makes much more sense and much more efficient to simply abandon subversion and migrate to pretty much any version control system. I'm not aware of any other system who forces users to install, manage and run servers just to track changes made to a file. How is this acceptable? Then you've never run CVS, Perforce, BitTracker, and half a dozen home brew systems I'm aware of that were written by CTO's who couldn't maintain anymore and which I replaced with Subversion. Whether it's one machine or not, when you want to have the same source control reository written to by multiple user accounts, a service (not necessarily an added server!!!) is a well known and well understood solution.
Re: Blocking root from SVN repository
Stefan Sperling s...@elego.de writes: That said, a one-line pre-commit hook script could check its UID and disallow the commit if it is invoked as root: if [ `whoami` == root ]; then exit 1; fi The start-commit is probably better than the pre-commit as there is no point allowing the transaction to start. The start-commit gets a username as $2 and the script could use that, but invoking whoami is probably better for the purpose of blocking root. For file:// access whoami and $2 will usually be the same but they could be different if --username is used. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 12:58 PM, Bob Archer bob.arc...@amsi.com wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? If so, you can use ssh+svn protocol, essentially running svnserve on demand. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. You don't need an svnserve daemon running for svn+ssh. It runs a temporary daemon, tied to that particular SSH session, owned by the same user who owns the SVN repo if it's configured correctly. Right, those were two separate suggestions. Use SSH+SVN or just run the svnserver daemon and use svn://
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 6:36 AM, D'Arcy J.M. Cain da...@vex.net wrote: I have read the posts about trying to deal with an untrusted root. I know that there is no point in even trying. That's not my issue. My issue is that sometimes I accidentally commit as root and files get changed to root ownership blocking normal access to the repository. All I want is something that recognizes root and prevents the commit. I don't care if it is easily overcome by root as long as root can choose not to do so. In other words, a warning would be good enough. It's basically a bad idea to use file:// access at all for anything that might be used under multiple user ids. Maybe even for a single user... Svnserve or http(s) access have much better access control and avoid the possibility of accidentally deleting or changing ownership through filesystem access. And it's also a bad idea to do things carelessly as root - programs generally can't second-guess that. -- Les Mikesell lesmikes...@gmail.com
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 07:49:30AM -0500, Les Mikesell wrote: On Wed, Aug 27, 2014 at 6:36 AM, D'Arcy J.M. Cain da...@vex.net wrote: I have read the posts about trying to deal with an untrusted root. I know that there is no point in even trying. That's not my issue. My issue is that sometimes I accidentally commit as root and files get changed to root ownership blocking normal access to the repository. All I want is something that recognizes root and prevents the commit. I don't care if it is easily overcome by root as long as root can choose not to do so. In other words, a warning would be good enough. It's basically a bad idea to use file:// access at all for anything that might be used under multiple user ids. Yes. The file:// URLs are intended for testing purposes, *not* production. That said, a one-line pre-commit hook script could check its UID and disallow the commit if it is invoked as root: if [ `whoami` == root ]; then exit 1; fi
Re: Blocking root from SVN repository
On 08/27/2014 01:49 PM, Les Mikesell wrote: It's basically a bad idea to usefile:// access at all for anything that might be used under multiple user ids. Maybe even for a single user... Well, that sucks. If file:// is not to be used then what are the available options to those who only need a local svn repository and don't have the option to set up a server? Zé
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 9:34 AM, Zé jose.pas...@gmx.com wrote: On 08/27/2014 01:49 PM, Les Mikesell wrote: It's basically a bad idea to usefile:// access at all for anything that might be used under multiple user ids. Maybe even for a single user... Well, that sucks. If file:// is not to be used then what are the available options to those who only need a local svn repository and don't have the option to set up a server? It's not that you can't use it, just that it can't protect you from the things that can happen through direct file system access. Like accidentally deleting the whole repo or changing ownership or permissions. If those things are important, then you (or if multiple users are involved, someone in your organization) should set up a server - it isn't difficult. -- Les Mikesell lesmikes...@gmail.com
Re: Blocking root from SVN repository
On 08/27/2014 03:53 PM, Les Mikesell wrote: It's not that you can't use it, just that it can't protect you from the things that can happen through direct file system access. Like accidentally deleting the whole repo or changing ownership or permissions. I don't see your point. There's also a likelihood that those accidents can happen on a remote server. But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued, then what are the available options for those who need a version control system and can't set up a server? Is it even possible to deploy subversion in that scenario? Zé
Re: Blocking root from SVN repository
On Wed, 27 Aug 2014 16:08:14 +, Zé wrote: ... I don't see your point. There's also a likelihood that those accidents can happen on a remote server. The difference being that anybody can accidentally do a rm -rf on the part after the file - anybody who can work with the repo. In a server setup, only the server admin account could do so, and only when the admin is logged onto the server. But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued, then what are the available options for those who need a version control system and can't set up a server? When you have a machine to place the file:// to, you also have something to run a server on. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 11:15 AM, Andreas Krey a.k...@gmx.de wrote: On Wed, 27 Aug 2014 16:08:14 +, Zé wrote: ... I don't see your point. There's also a likelihood that those accidents can happen on a remote server. The difference being that anybody can accidentally do a rm -rf on the part after the file - anybody who can work with the repo. In a server setup, only the server admin account could do so, and only when the admin is logged onto the server. But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued, then what are the available options for those who need a version control system and can't set up a server? When you have a machine to place the file:// to, you also have something to run a server on. I could (although it would be a horrible idea) put a repository on a file server and access it with file://, but I don't have the ability to run a proper server on that (nor would I want to mix roles in such a way).
Re: Blocking root from SVN repository
On 08/27/2014 04:15 PM, Andreas Krey wrote: The difference being that anybody can accidentally do a rm -rf on the part after the file - anybody who can work with the repo. (...) When you have a machine to place thefile:// to, you also have something to run a server on. If the machine you place the file:// is the same where you can accidentallly do a rm -rf, accessing the file:// through a server won't help you with that problem. Additionally, to those security-concious people, installing servers on your workstation just to access local repositories isn't exactly on the top of best practices. Don't you agree? And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 10:08 AM, Zé jose.pas...@gmx.com wrote: On 08/27/2014 03:53 PM, Les Mikesell wrote: It's not that you can't use it, just that it can't protect you from the things that can happen through direct file system access. Like accidentally deleting the whole repo or changing ownership or permissions. I don't see your point. There's also a likelihood that those accidents can happen on a remote server. Accidents can happen anywhere, but having files that are not writable by ordinary users greatly reduces the possibility and having them on a separate machine where only experienced administrators log in at shell level even more so. But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued, then what are the available options for those who need a version control system and can't set up a server? Is it even possible to deploy subversion in that scenario? There is nothing specific about subversion that is a problem with file:// access. It is just the nature of having direct write access to anything that makes it a fragile situation. With svn:// or http:// access there is nothing a client can do to delete data or change access for anyone else. With file access it is as easy as typing 'rm -rf in the wrong place since you have to have write access to use it at all. -- Les Mikesell lesmikes...@gmail.com
Re: Blocking root from SVN repository
On Aug 27, 2014, at 10:28 AM, Zé wrote: Additionally, to those security-concious people, installing servers on your workstation just to access local repositories isn't exactly on the top of best practices. Don't you agree? And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? You are recommended to run a Subversion server process (svnserve or Apache http with mod_dav_svn) on the computer on whose disk the repository resides. There is no problem with this computer being your local workstation. This needn't be inherently insecure, as you imply; you needn't open that server process up to any external network connections, for example.
Re: Blocking root from SVN repository
Zé wrote: On 08/27/2014 01:49 PM, Les Mikesell wrote: It's basically a bad idea to usefile:// access at all for anything that might be used under multiple user ids. Maybe even for a single user... Well, that sucks. If file:// is not to be used then what are the available options to those who only need a local svn repository and don't have the option to set up a server? I've used svnserve instances running under my own user account rather than use file://. Access is all via localhost, doesn't require special privileges, and can run on any port you like, either on a when needed basis or as a daemon. -kgd
Re: Blocking root from SVN repository
At Wed, 27 Aug 2014 16:08:14 +0100 =?UTF-8?B?WsOp?= jose.pas...@gmx.com wrote: On 08/27/2014 03:53 PM, Les Mikesell wrote: It's not that you can't use it, just that it can't protect you from the things that can happen through direct file system access. Like accidentally deleting the whole repo or changing ownership or permissions. I don't see your point. There's also a likelihood that those accidents can happen on a remote server. With a 'server' one can set the permissions such that no one but the server user (or root) can mess with the files, by making the files owned by a dedicated UID which is the UID that the server process runs under, so only the server process can access the files in the repo. If this user's shell is /bin/nologin it becomes impossible to gain a shell process running as this effective user. (Yes, root can still mess with things, but if a rogue user gains root access, you have bigger problems. Presumably a legit system admin knows not to use random direct file system tools on the repo files.) With file://, anybody who can do svn commit to file://..., can *also* use any of the standard file system tools (eg rm, mv, etc.) to mess with the files in the repo. And there really isn't any need for a 'remote server'. Note: there are two meanings for the term 'server': 1) A dedicated computer (typically headless) that is used to provide various network services to other computers on a network (LAN or WAN). 2) A *process* running on any computer that provides services to either other processes on that computer and/or to other computers on a network (LAN or WAN). I don't believe the people avocating against the use of file:// are specificly suggesting a server meaning definitation 1, but are most likely suggesting a server meaning definitation 2, which *could* be on a server meaning definitation 1, but does not have to be -- any Linux desktop can run server processes (as in meaning 2), including Apache (eg http:// or https://) or svnserver (svn:// or ssh+svn://). (I believe it is also easy to set up server processes on (desktop) Macs and I believe it is even possible to set up server processes on MS-Windows *desktop* machines as well.) But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued, then what are the available options for those who need a version control system and can't set up a server? Is it even possible to deploy subversion in that scenario? Zé -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 10:28 AM, Zé jose.pas...@gmx.com wrote: And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? The answer isn't going to change, no matter how many times we repeat it. Subversion works with file:// access, but it can't protect you from all the other ways that the filesystem allows write access and it can't work that way without write access. If that bothers you, set up a server - or just keep good backups and realize that if you switch to a backup repository copy that is not exactly in sync, you need to check workspaces back out again.If you really can't set up a server you might be better off with one of the version control systems that are intended to have distributed copies - and keep several, updated frequently. Subversion's real advantage is where you want one centrally-managed and authoritative copy. But I don't understand why you can't set up a server when the advantages it provides seem important to you. -- Les Mikesell lesmikes...@gmail.com
Re: Blocking root from SVN repository
On Aug 27, 2014, at 8:41 AM, Les Mikesell lesmikes...@gmail.com wrote: On Wed, Aug 27, 2014 at 10:28 AM, Zé jose.pas...@gmx.com wrote: And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? The answer isn't going to change, no matter how many times we repeat it. Subversion works with file:// access, but it can't protect you from all the other ways that the filesystem allows write access and it can't work that way without write access... I would like to point out that this is not a subversion-only situation. A git repository that uses direct file access for push/pull activities would suffer the same risk of permissions flipping. The problem is with the direct file access method when multiple users (UIDs) need access to the same set of files.
Re: Blocking root from SVN repository
At Wed, 27 Aug 2014 16:28:46 +0100 =?ISO-8859-1?Q?Z=E9?= jose.pas...@gmx.com
wrote:
On 08/27/2014 04:15 PM, Andreas Krey wrote:
The difference being that anybody can accidentally do a rm -rf on the
part after the file - anybody who can work with the repo.
(...)
When you have a machine to place thefile:// to, you also have
something to run a server on.
If the machine you place the file:// is the same where you can
accidentallly do a rm -rf, accessing the file:// through a server won't
help you with that problem.
Yes it will. With file://, the file ownership and permissions are such that
accidentallly doing a rm -rf would be a disaster. With svnserver or Apache,
the *ownershiip and permissions* should be such that doing a rm -rf *as a
normal user* (even one normally granted access to the repo via snv:// or
http://) will only raise an error ('you don't have permission to do that').
Running a *properly* set up svnserver or Apache + mod_dav_svn, means the files
in the repo are owned by a special user (eg svn:svn or apache:apache), for
which there is no login and only this special user has write access. People
using the repo are granted access via a separate mechanism and all actual
access to the repo's files is via the server process(es).
Additionally, to those security-concious people, installing servers on
your workstation just to access local repositories isn't exactly on the
top of best practices. Don't you agree?
Not necessarily. It depends on how you do it and how you set up the ownership
and privs. If done properly, it is safer than file://.
And I hate to repeat myself, but I'll repeat for the third time this
question: if file:// is not intended to be used, then what are the
available options for those who need a version control system and can't
set up a server?
Zé
--
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services
Re: Blocking root from SVN repository
On Aug 27, 2014, at 8:28 AM, Zé jose.pas...@gmx.com wrote: Additionally, to those security-concious people, installing servers on your workstation just to access local repositories isn't exactly on the top of best practices. Don't you agree? Not at all. Running a server which only answers to calls via the loopback interface (or local-domain sockets) is quite common. In fact, look at your machine's own process list. You will find a large number of helper processes that run with UIDs other than as root. The point of separating your repository access to a server process allows you to insulate file access permissions to one UID separate from your own (priviledge separation). If all users on a single box access the repository through this server process, you create a layer of abstraction and prevent file ownership/permissions flipping and actually _increase_ security and preserve the integrity of your repo.
Re: Blocking root from SVN repository
On Aug 27, 2014, at 10:08, Zé jose.pas...@gmx.com wrote: On 08/27/2014 03:53 PM, Les Mikesell wrote: It's not that you can't use it, just that it can't protect you from the things that can happen through direct file system access. Like accidentally deleting the whole repo or changing ownership or permissions. But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued Pretty sure Les just said, It's not that you can't use it. Which means you *can* use it. So the question you keep asking is based on a false premise.
RE: Blocking root from SVN repository
-Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? If so, you can use ssh+svn protocol, essentially running svnserve on demand. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation.
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 10:34 AM, Zé jose.pas...@gmx.com wrote: On 08/27/2014 01:49 PM, Les Mikesell wrote: It's basically a bad idea to usefile:// access at all for anything that might be used under multiple user ids. Maybe even for a single user... Well, that sucks. If file:// is not to be used then what are the available options to those who only need a local svn repository and don't have the option to set up a server? SSH key based access? Properly configured setgid permissions?
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 12:58 PM, Bob Archer bob.arc...@amsi.com wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? If so, you can use ssh+svn protocol, essentially running svnserve on demand. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. You don't need an svnserve daemon running for svn+ssh. It runs a temporary daemon, tied to that particular SSH session, owned by the same user who owns the SVN repo if it's configured correctly.
