Blocking root from SVN repository
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. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: Blocking root from SVN repository
On Wed, Aug 27, 2014 at 6:36 AM, D'Arcy J.M. Cain 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 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é 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 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 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é 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?= 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é 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 wrote: > On Wed, Aug 27, 2014 at 10:28 AM, Zé 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?=
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é 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é 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é 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 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.
