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

RE: Bug? FSFS revision control

From: Dassi, Nasser <NDassi_at_141xm.com>
Date: 2005-01-27 00:04:41 CET


Wouldn't it be nice to not blame the OS for everything? Wouldn't it be
nice if write access was not the *only* way to cause havoc to an
oh-so-precious version control solution?

If manual manipulation of a physical compact disc is required to render
the integrity of the data stored on said CD useless, then would it not
be a similarly reassuring experience to know that the integrity of the
version control history can only be manipulated in a couple of ways
(i.e. destroyed disk drive, reformatting the entire disk drive, or a
root superuser deleting the *entire* repository).

But plain "write" access should not mean "oh well, integrity goes
bye-bye" on any kind of data. If write access to the repository were
*only* permitted and achieveable through the Subversion application, and
not just Notepad, then that already mitigates the basic worries of
Repository Data Integrity.

Instead, Subversion should create a XXX.1 file to enumerate the number
of times a specific number was attained (if the original XXX file still
exists). This would at the very least disallow overtly LOSING any data
directly (because SVN overwrites the XXX file right now in an FSFS

At the very least the revision counter should not get so easily
adjusted. In all honesty, data integrity should not get jeopardized by
opening Notepad!

Nasser Dassi
Sr. Technical Programmer
E: ndassi@141xm.com

-----Original Message-----
From: Sean Laurent [mailto:sean@neuronfarm.com]
Sent: Wednesday, January 26, 2005 5:35 PM
To: users@subversion.tigris.org
Subject: Re: Bug? FSFS revision control

Hash: SHA1

On Wednesday 26 January 2005 04:10 pm, Dassi, Nasser wrote:
> > > There are several ways; and giving up so easily is extremely *bad*
> > > practice. Making a hacker think a few minutes is better than just
> > > giving them the answer without a blink.
> >
> > 1) The best way to do that is to secure the server itself.
> >
> > 2) Security through obfuscation does not work.
> Security through negligence works less than through obfuscation.
> Ironically, negligence carries a greater legal penalty than
> obfuscation!!!

I guess I'm just not seeing how modifying the FSFS backend would

Let's assume an malicious user gains unauthorized access to a server.
the exploited a security hole that allowed them to run a script as an
arbitrary user. Perhaps they cracked a user's password or worse yet,
root password. It doesn't really matter.

If the hacker has write access to the Subversion repository and they
want to
cause harm, why would they bother to edit the revision history? As Toby

Johnson already pointed out, if a user has write access to the
they could destroy the entire repository!

The best way to prevent this is to use the existing OS access controls,
the repository directories and restrict access to them. Why add a level
complexity to Subversion that won't help solve the problem?

- -Sean
Version: GnuPG v1.2.4 (GNU/Linux)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 27 00:08:51 2005

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.