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