Robert Cragie writes:
>
> Trying to get to the bottom of the /root/.cvsignore problem which lots of
> people seem to be complaining about...
There's nothing to get to the bottom of -- it's a well-understood
problem at this point. get_homedir() figures out the home directory the
first time it is called and simply returns the same string again on each
subsequent call. If CVS changes the user it's running as (which pserver
usually does) after the first time get_homedir() is called, the result
will no long be correct. To prevent that, it is necessary to use the -f
global option when running pserver, which the current released version
of the Cederqvist manual recommends. (One could argue that pserver
should automatically imply -f -- I haven't thought things through enough
to decide whether there's ever any reason to want it to work the other
way or not.)
What causes the problem in most cases is that get_homedir() assumes that
$HOME is either unset or set correctly. On certain systems (only Linux
as far as I know), processes started by inetd have $HOME set, typically
to root's home directory, which is *NOT* correct if CVS changes user. I
consider this to be a bug -- there is no reason that I can think of for
$HOME to be set for server processes, traditional inetd implementations
don't do it, and I've never heard any justification for it. People with
such systems are thus encouraged to report it to whomever maintains them
so that this bug can be fixed. In the meantime, they need to work
around the problem, either by using env to run CVS with an empty
environment or by running a shell script that unsets $HOME and then runs
CVS. This is mentioned in the current development version of the
Cederqvist manual, so it will be in the next release.
> 1) No caller of get_homedir() seems to free the returned string. Is this
> correct?
Yes -- it's a permanently allocated string. (Note that subsequent calls
return the exact same pointer, so freeing it would be disasterous.)
> 2) char *env - does getenv() return a malloc'ed string? man pages suggest
> no, so this seems OK
It is.
> 3) struct passwd *pw - does getpwuid() return (ptr. to) a malloc'ed struct?
> man pages suggest YES, so this looks buggy.
No, it returns a pointer to an internal, possibly static, struct. The
contents are only guaranteed until the next call to a password access
function which is why we strdup() the part we need.
> 4) xstrdup() returns a malloc'ed string; this will never be freed if (1) is
> true.
Correct; that's the way it's supposed to work.
> Therefore, the only way this will currently run OK is if HOME is set (which
> I guess is usually the case).
No, it works correctly in either case.
-Larry Jones
He doesn't complain, but his self-righteousness sure gets on my nerves.
-- Calvin
