You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Peacock <jp...@rowman.com> on 2006/12/13 22:02:32 UTC
Bug in SVN::Client
I went to install the bleading edge SVN::Web (now with SVN::Client
support for remote repositories) and it worked fine in tests, but fails
when run as a mod_perl script. I've now confirmed that the failure is
actually the fault of SVN::Client.
Attached is a script which needs to be run like this:
$ sudo ./test
which results in the following error message:
> Permission denied: Can't open file '/root/.subversion/servers': Permission denied at ./test line 26
The issue came up because Apache drops privileges exactly like the
script does, and SVN::Client->new() tries to open the real UID's
.subversion directory (which is can't), not the effective UID's
directory. I haven't looked at the code yet to figure out what is going
wrong (too busy trying to work out whether it was mod_perl's fault instead).
Details:
Subversion 1.4.2 built from source with Apache 2.2.0 and APR 1.2.2
Perl v5.8.8
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug in SVN::Client
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> I'm not exactly sure why you've decided that the environment variable
> approach is fundamentally broken.
It's not that it is fundamentally broken; it is just remarkably fragile
in the face of the common behavior of running server tasks in a
restricted environment. If you make the assumption that the exposure of
this behavior is limited to "user-initiated execution" then it is
reasonable to rely on the convention that $HOME (or the Win32
equivalent) contains a valid path. It was a rude surprise, however,
that executing the client libraries under mod_perl (which is most
certainly *not* a normal user environment) would behave so badly for
little or no reason.
> That said, I'm certainly not convinced that erroring out is required,
> especially given my recollection that the code doesn't care if the
> .subversion directory is present and readable yet empty.
Since I don't have anything more important to contribute to the project
at the moment, I'll try to take on this [hopefully bite-sized] task and
produce a patch to reduce the error to a warning. It won't be until
after winter break however (unless I get some time to myself on vacation).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug in SVN::Client
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock wrote:
> John Peacock wrote:
>> No that doesn't fix it; it really is due to the real UID being 0 and the
>> effective UID not having access to root's files. I've traced back as
>> far as svn_config_get_config() but I haven't worked my way back to
>> discover the algorithm that tries to find the HOME on it's own.
>
> This seems to be a very fragile design decision:
>
> $ HOME=/dev/null svn --version
> svn: Can't open config file '/dev/null/.subversion/servers'
>
> It makes no sense to me to depend on an environment variable (which anyone can
> monkey with), then die if that contains nonsense (or inaccessible files), when
> the configuration in question can legitimately be initialized as NULL with no
> harm. At the very minimum this should throw a warning; to have it error out is
> just overkill.
Within CollabNet, we've struggled quite a bit with this behavior. We
now have quite a few Python scripts that do this:
import pwd
os.environ['HOME'] = pwd.getpwuid(os.getuid())[5]
(replacing HOME with the effective UID's home directory).
I'm not exactly sure why you've decided that the environment variable
approach is fundamentally broken. It's not, actually, the case that
"anyone can monkey with" them -- you sorta have be the (one) someone in
the particular environment, right? And my understanding is that the use
of $HOME on Unix-y platforms and the relevant registry keys in Windows
(which we, in fact, do use via apr_homepath_get) are the more-or-less
universally accepted ways of answering the question, "Where is this
user's home directory?"
That said, I'm certainly not convinced that erroring out is required,
especially given my recollection that the code doesn't care if the
.subversion directory is present and readable yet empty. Obviously,
Subversion doesn't *need* the config hash populated. I suspect, in the
end, that this behavior is just an oversight, and that pretty much any
error which occurs while reading the configuration area can just be
eaten up silently.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug in SVN::Client
Posted by John Peacock <jp...@rowman.com>.
John Peacock wrote:
> No that doesn't fix it; it really is due to the real UID being 0 and the
> effective UID not having access to root's files. I've traced back as
> far as svn_config_get_config() but I haven't worked my way back to
> discover the algorithm that tries to find the HOME on it's own.
This seems to be a very fragile design decision:
$ HOME=/dev/null svn --version
svn: Can't open config file '/dev/null/.subversion/servers'
It makes no sense to me to depend on an environment variable (which anyone can
monkey with), then die if that contains nonsense (or inaccessible files), when
the configuration in question can legitimately be initialized as NULL with no
harm. At the very minimum this should throw a warning; to have it error out is
just overkill.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug in SVN::Client
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> Saw no attached script, but, I mean, is there really a bug here? When
> you run 'sudo', the HOME environment variable is left as that of the
> real UID. Does the problem go away when you run 'sudo -H ./test' ?
No that doesn't fix it; it really is due to the real UID being 0 and the
effective UID not having access to root's files. I've traced back as
far as svn_config_get_config() but I haven't worked my way back to
discover the algorithm that tries to find the HOME on it's own.
But more importantly if I change the initializer to be this:
my $client = SVN::Client->new(config=>{});
then the test file succeeds (and indeed this fixes SVN::Web as well).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug in SVN::Client
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock wrote:
> I went to install the bleading edge SVN::Web (now with SVN::Client
> support for remote repositories) and it worked fine in tests, but fails
> when run as a mod_perl script. I've now confirmed that the failure is
> actually the fault of SVN::Client.
>
> Attached is a script which needs to be run like this:
>
> $ sudo ./test
>
> which results in the following error message:
>
>> Permission denied: Can't open file '/root/.subversion/servers':
>> Permission denied at ./test line 26
Saw no attached script, but, I mean, is there really a bug here? When
you run 'sudo', the HOME environment variable is left as that of the
real UID. Does the problem go away when you run 'sudo -H ./test' ?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug in SVN::Client
Posted by John Peacock <jp...@rowman.com>.
Nik Clayton wrote:
> FWIW, http://jc.ngo.org.uk/svnweb/ is running the svn-client code under
> mod_perl, with Apache started as root before it switches to the 'www'
> user, and it's not exhibiting the problem either. This is in a FreeBSD
> 4.10 jail (virtual server).
Then this may be a 'BSD vs Linux' specific issue since I can't run it
under mod_perl unless I include my patch.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug in SVN::Client
Posted by Nik Clayton <ni...@ngo.org.uk>.
John Peacock wrote:
> I went to install the bleading edge SVN::Web (now with SVN::Client
> support for remote repositories) and it worked fine in tests, but fails
> when run as a mod_perl script. I've now confirmed that the failure is
> actually the fault of SVN::Client.
>
> Attached is a script which needs to be run like this:
>
> $ sudo ./test
>
> which results in the following error message:
>
>> Permission denied: Can't open file '/root/.subversion/servers':
>> Permission denied at ./test line 26
I can't replicate this.
I'm using sudo 1.6.8.12. I ran a total of four tests. The first two are
with Subversion 1.4.0, one with sudo compiled with the --shell-sets-home
option and one without. Both times the command completed successfully (and
dumped the contents of the ::Client object).
Then I tried the same two tests, but upgraded Subversion to 1.4.2. I got
the same result.
FWIW, http://jc.ngo.org.uk/svnweb/ is running the svn-client code under
mod_perl, with Apache started as root before it switches to the 'www' user,
and it's not exhibiting the problem either. This is in a FreeBSD 4.10 jail
(virtual server).
The
/usr/bin/env HOME=/dev/null svn --version
test mentioned in a later message fails as expected.
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug in SVN::Client
Posted by John Peacock <jp...@rowman.com>.
John Peacock wrote:
> Attached is a script which needs to be run like this:
Duh. This time with the script attached... :(
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748