You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Felix Brack <fb...@ltec.ch> on 2005/06/23 12:36:58 UTC
Problems after upgrade 1.1.4 -> 1.2.0
I used subversion 1.1.x for quite a while together with 'tortoise' and
'websvn'. After upgrading to subversion 1.2.0 'tortoise' still works,
but I do have permission problems with 'websvn'.
My apache 2 server runs as user 'nobody' and group 'svn'. 'nobody' is
member of group 'svn'.
I use the following PHP script to reproduce the error:
01 <?php
02 $fp= popen("/usr/local/bin/svn list 'file:////home/svnroot/repositories/test/'", "r");
03 // $fp= popen("/usr/local/bin/svn list 'http://svn.jupiter.ltec/svn/test/'", "r");
04 // $fp= popen("ls -l", "r");
05
06 while (!feof($fp)) {
07 $line= fgets($fp);
08 echo "Line: ${line}<br>";
09 }
10
11 pclose($fp);
12 ?>
If this script is executed by apache, I can't see any output and
apache's error log says:
'svn: Can't check path '/root/.subversion': Permission denied'
Why is something (?) accessing this path?
When I open a console on the server hosting the svn repository,
log in as 'nobody' and run the script above through the PHP
interpreter, everything is fine.
There is no change if I replace the 'file:' syntax by the 'http:'
syntax.
The test command 'ls -l' works fine, no matter if I use apache or the
console to invoke it.
Even after reading http://subversion.tigris.org/faq.html#reposperms
and http://svnbook.red-bean.com/en/1.0/ch06s05.html and don't have any
idea what I'm doing wrong.
-------------------------
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems after upgrade 1.1.4 -> 1.2.0
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 23, 2005, at 7:36 AM, Felix Brack wrote:
> 'svn: Can't check path '/root/.subversion': Permission denied'
> Why is something (?) accessing this path?
Some process -- either PHP or websvn -- is running 'svn' as a user
that thinks $HOME is equal to "/root". It's that simple.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems after upgrade 1.1.4 -> 1.2.0
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 24, 2005, at 6:57 AM, Felix Brack wrote:
>
> There is just one question remaining here; maybe someone can give me
> an answer: did anything change from subversion 1.1.4 to 1.2.0 that
> could explain the problem?
Not that I can think of. Subversion has always accessed
$HOME/.subversion/, ever since 1.0. So I have no idea why you
wouldn't have seen this before.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems after upgrade 1.1.4 -> 1.2.0
Posted by Felix Brack <fb...@ltec.ch>.
First of all, thanks for your help that put me on the right way. After
some analyzing I can now tell what's happening:
Apache is started as root, it's child processes run with privileges of
user 'nobody'. Therefore when websvn executes the subversion command
'svn ...', it does this 'as user nobody'. 'svn' then tries to access
$HOME/.subversion. Since $HOME points to /root and not to /home/nobody, the
access fails with 'permission denied'. Changing the call from 'svn ...'
to 'svn --config-dir /home/nobody ...' solves the problem.
Conclusion: this is definitely not a problem of subversion.
There is just one question remaining here; maybe someone can give me
an answer: did anything change from subversion 1.1.4 to 1.2.0 that
could explain the problem? Since subversion is the only component I
upgraded (apache httpd, php and websvn are unchanged) the answer to
this question would really help me to fix the problem where it really
is.
-------------------------
Felix
Felix Brack wrote:
FB> I used subversion 1.1.x for quite a while together with 'tortoise' and
FB> 'websvn'. After upgrading to subversion 1.2.0 'tortoise' still works,
FB> but I do have permission problems with 'websvn'.
FB> My apache 2 server runs as user 'nobody' and group 'svn'. 'nobody' is
FB> member of group 'svn'.
FB> I use the following PHP script to reproduce the error:
FB> 01 <?php
FB> 02 $fp= popen("/usr/local/bin/svn list
FB> 'file:////home/svnroot/repositories/test/'", "r");
FB> 03 // $fp= popen("/usr/local/bin/svn list
FB> 'http://svn.jupiter.ltec/svn/test/'", "r");
FB> 04 // $fp= popen("ls -l", "r");
FB> 05
FB> 06 while (!feof($fp)) {
FB> 07 $line= fgets($fp);
FB> 08 echo "Line: ${line}<br>";
FB> 09 }
FB> 10
FB> 11 pclose($fp);
12 ?>>
FB> If this script is executed by apache, I can't see any output and
FB> apache's error log says:
FB> 'svn: Can't check path '/root/.subversion': Permission denied'
FB> Why is something (?) accessing this path?
FB> When I open a console on the server hosting the svn repository,
FB> log in as 'nobody' and run the script above through the PHP
FB> interpreter, everything is fine.
FB> There is no change if I replace the 'file:' syntax by the 'http:'
FB> syntax.
FB> The test command 'ls -l' works fine, no matter if I use apache or the
FB> console to invoke it.
FB> Even after reading
FB> http://subversion.tigris.org/faq.html#reposperms
FB> and http://svnbook.red-bean.com/en/1.0/ch06s05.html and don't have any
FB> idea what I'm doing wrong.
FB> -------------------------
FB> Felix
FB> ---------------------------------------------------------------------
FB> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
FB> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems after upgrade 1.1.4 -> 1.2.0
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 23.06.2005, at 15:20, Marc Haisenko wrote:
> On Thursday 23 June 2005 15:14, Ryan Schmidt wrote:
>
>> - Delete /root/.subversion and Subversion won't look for it anymore.
>> Of course, something will most likely recreate it later, when you
>> least expect it, and break it again.
>
> Since on almost all system /root has permissions 700 only root can
> stat /root/.subversion, so this simply won't work.
I'm not sure what you're saying; let me clarify what I'm saying:
- Some process that was run as root caused the /root/.subversion
directory to come into existence. For example, I believe running any
Subversion command will do this.
- You could log in as root and delete the directory. I think this
would work, as long as you never run any Subversion command as root
again.
- As soon as you do run another Subversion command as root, the /
root/.subversion directory gets recreated, recreating the problem.
- Therefore, removing the directory is probably not the best long-
term solution.
- The better solution I think is to give the web user ("nobody") its
own home directory where it can put its own .subversion directory
that it will own and that nobody else will mess up.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems after upgrade 1.1.4 -> 1.2.0
Posted by Marc Haisenko <ha...@webport.de>.
On Thursday 23 June 2005 15:14, Ryan Schmidt wrote:
> - Delete /root/.subversion and Subversion won't look for it anymore.
> Of course, something will most likely recreate it later, when you
> least expect it, and break it again.
Since on almost all system /root has permissions 700 only root can
stat /root/.subversion, so this simply won't work.
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems after upgrade 1.1.4 -> 1.2.0
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 23.06.2005, at 14:36, Felix Brack wrote:
> My apache 2 server runs as user 'nobody' and group 'svn'. 'nobody' is
> member of group 'svn'.
>
> I use the following PHP script to reproduce the error:
>
> 01 <?php
> 02 $fp= popen("/usr/local/bin/svn list 'file:////home/
> svnroot/repositories/test/'", "r");
> 03 // $fp= popen("/usr/local/bin/svn list 'http://
> svn.jupiter.ltec/svn/test/'", "r");
> 04 // $fp= popen("ls -l", "r");
> 05
> 06 while (!feof($fp)) {
> 07 $line= fgets($fp);
> 08 echo "Line: ${line}<br>";
> 09 }
> 10
> 11 pclose($fp);
> 12 ?>
>
> If this script is executed by apache, I can't see any output and
> apache's error log says:
> 'svn: Can't check path '/root/.subversion': Permission denied'
> Why is something (?) accessing this path?
>
> When I open a console on the server hosting the svn repository,
> log in as 'nobody' and run the script above through the PHP
> interpreter, everything is fine.
The subversion client checks for a directory ".subversion" in the
current user's home directory; it contains configuration information.
Not sure why it's looking in root's home directory then. Maybe
"nobody" doesn't have a home directory defined, and is falling back
to root's? I might also have said that "nobody" might not have a
login shell, but the fact that you can log in as "nobody" to run the
script, as you state above, seems to indicate otherwise.
Some possibilities off the top of my head:
- Delete /root/.subversion and Subversion won't look for it anymore.
Of course, something will most likely recreate it later, when you
least expect it, and break it again.
- Give "nobody" a home directory so Subversion looks there for
its .subversion directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org