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 <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Dec 14 04:25:27 2006