RE: "Flaw" revisited (was: Bug? FSFS revision control)

In my personal experience, #4 is the best solution to mitigate this problem.
The only other thing that runs on my SVN server is SVN::Web for browsing the
repo. The server only listens on the specific IP for SVN, so that the
regular web server can still listen on a standard port but run as a
different user in a different root. Users do not have filesystem-level
access to the repo, and the only operations that use file:/// are hook
scripts.

I also try (as best I can) to never use svnadmin unless the web server is
down or I can otherwise ensure that concurrent access isn't attempted.

These measures don't strike me as particularly draconian, and given SVN's
design goals, the fact that I can isolate users to only using HTTPS is a
huge benefit over CVS.

Regards

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2004@ryandesign.com]
Sent: Saturday, January 29, 2005 1:15 PM
To: Subversion List
Subject: Re: "Flaw" revisited (was: Bug? FSFS revision control)

On 27.01.2005, at 14:50, MikeM wrote:

> On 1/26/2005 at 11:40 PM Dassi, Nasser wrote:
>
>> |2. Do you feel bothered that modifying a single number value from a
>> |text-based file can and would result in the rewriting of the
>> repository's
>> |very own revision history?
>
> Why does that person have write access to that file?

I hate to contribute to this thread, but there has been a little nagging
concern of mine since I started reading about Subversion. I have not yet set
up my repository, so maybe this will all become clear when I do.

I plan to use Apache as the only method of serving the repository to my
users. I believe this means that the repository directory and the files in
it should be owned by the same user and group as the apache process, right?
If I'm wrong here, then this is the source of my confusion, but it would
seem that if the repository were owned by some other user, then there could
be no commits to the repository.

The concern is that if the repository is owned by the apache user, then
anything running on the web server could modify the repository (that is,
modify/corrupt/delete the repository files directly). We use Apache as a
regular web server already, serving web pages for dozens of projects, some
programmed by us and some not. What if one of these projects has a security
flaw that allows arbitrary command execution as the apache user (such as the
recent phpBB bug)?

I can think of a number of possible responses

1) The above is not a problem because some of the above assumptions are
incorrect.
2) The above is not a problem because it is assumed that all users who
access systems on this web server are trusted -- that is, there is
authentication in place protecting all web systems on this server. (We
actually do have this, but I can imagine cases where this would not be
desirable.)
3) The above is not a problem because it is assumed that all web systems on
this server do not have any security flaws.
4) The above is not a problem because it is assumed that the Apache server
used to serve the repository is not used to serve other web systems.
5) Something else?

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

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.2 - Release Date: 1/28/2005
 
-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.2 - Release Date: 1/28/2005
 
-- 
----------------------------------------------------------------------------
This electronic message contains information from Primus Telecommunications
Canada Inc. ("PRIMUS") , which may be legally privileged and confidential.
The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or e-mail (to the number or address above)
immediately. Any views, opinions or advice expressed in this electronic
message are not necessarily the views, opinions or advice of PRIMUS.
It is the responsibility of the recipient to ensure that
any attachments are virus free and PRIMUS bears no responsibility
for any loss or damage arising in any way from the use
thereof.The term "PRIMUS" includes its affiliates.
----------------------------------------------------------------------------
Pour la version en fran�ais de ce message, veuillez voir
 http://www.primustel.ca/fr/legal/cs.htm
----------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org