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

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

From: Ryan Schmidt <subversion-2004_at_ryandesign.com>
Date: 2005-01-29 19:14:52 CET

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
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
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
5) Something else?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 31 12:07:25 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.