Bug 10231

Here's a quick diff that, sacrificing reentrance completely, at least gets
around this beast.

diff -uNr cvs-1.10.7-orig/src/filesubr.c cvs-1.10.7/src/filesubr.c
--- cvs-1.10.7-orig/src/filesubr.c      Mon Aug 24 11:40:17 1998
+++ cvs-1.10.7/src/filesubr.c   Sun Mar 19 06:37:54 2000
@@ -813,8 +813,10 @@
     char *env = getenv ("HOME");
     struct passwd *pw;

-    if (home != NULL)
-       return home;
+    /*
+    if (home != NULL) {
+    }
+    */

     if (env)
        home = env;

Did you try resetting your HOME environment variable? I'm reluctant
to apply a patch that can be more easily handled by changing the environment.

Can you supply more details also? I use cvs daily and have not encountered
the problem for which the patch "fixes".

Either you haven't specified @samp{-f} in @file{inetd.conf}
or your system is setting the @code{HOME} environment variable
for programs being run by inetd.  In the latter case, you can either
have inetd run a shell script that unsets @code{HOME} and then runs
@sc{cvs}, or you can use @code{env} to run @sc{cvs} with a pristine
environment.

(the above text is from the development version of the CVS manual, but it
also applies to older versions of CVS).

Neither is the case.  I tried the -f option, with no luck.  I was unable to
confirm any behavioural change int he program at all using this switch in my
inetd.conf file.

During my testing of the program, I verified that there is a period of time
where the program is, as a user, attempting to access /root/.cvsignore.  My
testing procedure did include some simple printf(stderr, ..) of the value of
home at that point.  It did show my user directory (/home/bishop) as well as
/root.

I am unsure as to how I could conceivably alter server configuration code, via
scripts and wrappers, so as NOT to impact the bahaviour that I saw.  In a case
where I'm the only person ever using this cvs server (I'd use rcs instead, then,
but) I could surely make the server un as bishop and not as root.

Access on the formerly misbehaving system can be arranged, should you wish to
see the behaviour with your own eyes.  Who knows - you may find a bug to fix.

I added the following line to /etc/inetd.conf and HUP'ed inetd:

cvspserver	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/bin/env -i /usr/bin/cvs
--allow-root=/home/cvsroot pserver

The error still appears.  I have no choice but to apply the reentrance
sacrificing patch or make /root world writable.  By the way:

cvspserver	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/bin/cvs
--allow-root=/home/cvsroot pserver

used to work with Red Hat 6.0 and cvs 1.10.7.  Perhaps this is a PAM problem. 
The problem also exists with cvs 1.10.8 compiled without Kerberos support, so
that's not it.

I located the Debian patch, which fixes the problem.  You will find the author's
comments enlightening.  (I only applied the filesubr.c portion of the diff and
everything now works like a charm).

ftp://ftp.debian.org/debian/dists/potato/main/source/devel/cvs_1.10.7-7.diff.gz

this is 15 months old.  I'm closing it.

The latest Red Hat bug fix release for 6.2, 1.11.1p1-6.2, finally allows the -f
option.  So the following line now works without any patches:

cvspserver
stream
tcp
nowait
root
/usr/sbin/tcpd
/usr/bin/cvs -f --allow-root=<my CVS archive> --allow-root=<another CVS archive>
pserver
Be sure to HUP the PID of inetd after making this change.

Sorry, bugzilla or mozilla messed up the formatting of my message, but hopefully
you get the idea.