[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 01:03:48 CET

Mr. Parker,

1. A non-hacker can edit the number, and boom... Revisions gone. The
non-hacker is not determined to overwrite revisions... But hey, sh*t
happens! :)

2. SVN-accessed modifications (including dumping) is beyond the scope of
this concern. In fact, SVN-accessed actions are all by-design or at
least assumed.

3. My other post (same thread, minutes ago) examplifies how file locking
is possible without blaming the OS or sysadmin for stuff.

- nasser

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

-----Original Message-----
From: Mark Parker [mailto:mark@msdhub.com]
Sent: Wednesday, January 26, 2005 6:45 PM
To: Dassi, Nasser
Cc: users@subversion.tigris.org
Subject: Re: Bug? FSFS revision control

Dassi, Nasser wrote:
> **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).

OK, then when the hypothetical hacker wants you to lose information,
he'll just delete the xxx.1 file or rename it to xxx.0 or whatever. No.
Protection. Whatsoever.

> 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!

If not Notepad then your favorite hex editor. Binary formats are not
more secure just because you can't edit them in notepad. If someone has
OS-granted rights to the repository and wants you to lose data, then
you'll lose data. Even if the repository was totally encrypted, secure,
and unmodifiable via any known tool, that doesn't prevent someone from
doing:

svnadmin dump repo -r 0:some_old_revnum > dumped_repo rm -rf repo
svnadmin create repo -fs-type fsfs cat dumped_repo | svnadmin load repo
--force-uuid

In which case you've lost data, and didn't involve any notepadesque
tools whatsoever. Should svnadmin do a retinal scan to verify that
you're allowed to dump/load repositories?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 27 01:07:32 2005

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