Ryan Schmidt wrote:
> 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.
Your assumption is correct.
> 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?
The answer is, of course, "something else". :-)
Any kind of security flaw that gives malicious users access to the
server's filesystem is obviously a problem. Security flaws exist whether
we know about them or not, se the best you can do is try to minimise the
potential damage. In your particular case, you're already vulnerable
since those very same bugs could allow members of unrelated projects to
hack at each other's web pages/databases/whatever.
But it's fairly easy to protect the repository: you can, for example,
run a separate instance of Apache with a different user (perhaps in a
chroot) on a non-default port, and configure your main server to act as
a transparent proxy. This is a question of Apache configuration, not
Subversion "repository safety."
-- Brane
---------------------------------------------------------------------
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:25:10 2005