Because.
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.
**IMPORTANT**
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
backend).
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
-----BEGIN PGP SIGNED MESSAGE-----
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
actually
help.
Let's assume an malicious user gains unauthorized access to a server.
Perhaps
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,
the
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
repository,
they could destroy the entire repository!
The best way to prevent this is to use the existing OS access controls,
secure
the repository directories and restrict access to them. Why add a level
of
complexity to Subversion that won't help solve the problem?
- -Sean
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB+Br2zBEkVQQ0ejkRAiHCAKCWpS9UqiQhrm+TnybOq1ZniLeMPgCfbYxl
9m0Ezg8Sv81dEa2nsUYUdpk=
=UktE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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