Ryan Schmidt wrote:
> Bob Proulx wrote:
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> >That looks like the same PATH that is in effect for apache. I am sure
> >it is being inherited, just as desired.
>
> According to the documentation, the path should be empty:
>
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks
>
> > For security reasons, the Subversion repository executes hook
> > scripts with an empty environment—that is, no environment variables
> > are set at all, not even $PATH or %PATH%. Because of this, a lot of
> > administrators are baffled when their hook script runs fine by
> > hand, but doesn't work when run by Subversion. Be sure to
> > explicitly set environment variables in your hook and/or use
> > absolute paths to programs.
Wow. That is truly ugly. If an admin can't control PATH being used
by the hook scripts then there are problems well beyond security.
Because I can't believe that someone would feel there is a need to
purge PATH by design. That just feels so wrong to me.
> There have been many questions on this list over the past year where
> people wonder why their hook scripts don't work, and when they're
> told to use absolute paths, they respond saying that worked.
I would set PATH at the top of my script to something reasonable.
PATH=${PATH-/usr/local/bin:/usr/bin:/bin}
And then still avoid hard coded paths.
> I've tested this before, and again just now, by creating a new
> repository, creating a post-commit hook in it to log all the
> environment variables to a file, checking it out via the file:///
> protocol, and committing a change, and most environment variables,
> including PATH, are not set, just like the docs say.
Based upon your observation I just tested this again and what I see is
that my exported environment includes only PWD. But my shell
variables not exported includes PATH, SHELL and TERM. Because PATH
exists for the current shell, even though it is not exported, it
functions for commands in that shell. If I were to launch a child
shell script this would not show up there because it is not an
exported variable.
I believe this is a bash feature. Try this:
env -i bash
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
That is why this is working for me. Because bash is not finding any
PATH in the environment and therefore falling back to a compiled in
default. It sets it for its own use but does not export it.
Hmm... This tells me that I should export PATH in my hook scripts.
Although it does not really solve the problem.
export PATH
In a normal shell PATH is one of the special ones that is always
exported. Just changing it is enough. But with the env purge the
special status of it has been changed and while it is available for me
it is no longer exported.
> But I've also seen messages recently from Windows users saying the
> path is set, though it was set to an unexpected value.
The MS-Windows environment always frustrates me to no end and I avoid
it whenever possible. So hearing reports of problems there I usually
leave to the MS crowd to fix. But this data would indicate that it is
shell specific what compiled in PATH it would fallback to. I tested
ksh on HP-UX and it did not fall back to any built in PATH.
> Just now I created a test repository and served it via Apache, and
> was surprised to see that all the environment variables I have set in
> my shell were inherited by the hook script.
Exported? Or no? (The difference between 'env' and 'set'.)
> So either the documentation needs to be updated to explain when the
> environment will be empty and when it won't be, or the Subversion
> code needs to be changed to match the documented behavior.
Or better yet both updated to allow PATH. :-)
> I tested with Subversion 1.3.2 and Apache 2.2.2 on Mac OS X 10.4.6
> PPC G4.
Debian GNU/Linux stable/backports for me.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 1 02:56:54 2006