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

Re: Blocking root from SVN repository

From: Robert Heller <heller_at_deepsoft.com>
Date: Wed, 27 Aug 2014 11:40:31 -0400

At Wed, 27 Aug 2014 16:08:14 +0100 =?UTF-8?B?WsOp?= <jose.passes_at_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
heller_at_deepsoft.com       -- Webhosting Services
Received on 2014-08-27 17:41:10 CEST

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

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