[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: SVN::Client problem under mp2
From:       Enno <burglar () xs4all ! nl>
Date:       2006-04-19 13:54:22
Message-ID: 20060419154310.I45004-100000 () xs3 ! xs4all ! nl
[Download RAW message or body]

found the cause of the problem, apache 2.0.49 + mp 2.0.2 doesnt properly
change userid after start, eventhough effective userid is set properly,
the users homedir is still set to /root (under modperl)

svn::client tries to read a (useless) config file from ~/.subversion/
if it cant find it (ENOENT), its ok, but if it looks under /root, you'll
get a permission denied (EACCES), and svn libraries raise an exception.

now the weird problem, it works properly on a different box with an old
modperl (1.99_09), running on apache 2.0.54.

so I dont know if this is a problem with an older apache, or with a new
modperl2.

if anyone had similar problems with this (change effective userid), you
might be able to tell me if this is caused by apache or modperl.

thanks in advance.

Enno

On Tue, 18 Apr 2006, Enno wrote:

>
>
> On Tue, 18 Apr 2006, Tom Schindl wrote:
>
> > Enno wrote:
> > > Hey list,
> > >
> > > I ran into a nasty problem with SVN::Client under mp2.0.2. I simply want
> > > it to connect to an ssl svn server with a specified username and password.
> > >
> > > When I run the needed code from cmdline, everything works perfect, but
> > > when I try to run it using an mp2 handler, it craps out with the following
> > > errormessage:
> > >
> > > Bogus filename: Can't open config file '/root/.subversion/servers' at
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > That's really not what you may intent and your os knows how to prevent
> > you from apache reading files in /roots-HomeDir you should move this to
> > another location.
> >
> > > /srv/www/modules/testhandler.pm line 28
> > >
>
> yeah, but the it shouldnt even try to read that file... also, that
> path/file is not even present in the svn perl modules...
>
> so its gotta be somewhere in the C source, going to check that out
> tomorrow.
>
> Enno
>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]