I may have found something risky security and integrity-wise.
Issue:
The revision number with file-type FSFS is manually modifyable in any
ol' text editor. The value (in a file within the repository's file
structure) is stored in plain-text and can be edited with extreme ease.
Potential risk:
Whomever has access to the repository's directory (not via interfaces,
but directly at file-system level) can easily modify and alter and
possibly wipe clean the actual revision history.
How to reproduce:
1. Open notepad, and open the file "path-to-repo/db/current"
2a. Edit first number set (this is the revision number) to any desired
number.
2b. Once you save the file, the HEAD revision is whatever value you
input.
3. Update your working copy; expect "conflicts" to exist everywhere
based on whatever differences exist between the "current revision"
(manually input) and "youngest revision" (before modifying the version
number).
4. Mark any/all conflicts as resolved.
5. Commit. Your revision number is now your manually-input revision +
1.
Reproduced using:
Windows XP SP2 Professional
Subversion 1.1.1 (r11581) Server
Subversion 1.1.3 Client
TortoiseSVN 1.1.3 Client
Keep in mind:
The steps taken to reproduce are easily attainable in a command-line
approach with not GUI client.
Possible/suggested bug fix/workaround solutions:
1. Implement integrity checking to cause future modified-repository
commits to fail; or
2. Implement revision-locking at the filesystem level so existing
revprops + revs files are not *overwritten*; or
3. Revert to latest revision based on FSFS-stored revprops and revs file
trails; or
4. Implement encoding/encryption to reduce likelihood of tampering (as
Berkeley DB does)
- nasser
Nasser Dassi
Sr. Technical Programmer
=========================================
E: ndassi@141xm.com
=========================================
Received on Wed Jan 26 22:08:07 2005