CVS bug

[Zac Schroff]

NOTE on intellectual property rules for this message : The *content*
of the message itself may be used as stipulated by the CVS bug report
instructions, but the headers and footers may not.  My *name*, but
*not* email address, should used if attributions are made.  Discard
this message if this is not an acceptable stipulation.  Thank you.

I came across the message below, and found the entry for it in the
info file for CVS 1.11.6, and it still seems to be in the current
info file, with the same descriptive paragraph.  I believe I may have
some data to contribute toward tracking this problem (below).

 cvs [server aborted]: received broken pipe signal

    This message seems to be caused by a hard-to-track-down bug in CVS
    or the systems it runs on (we don't know--we haven't tracked it
    down yet!). It seems to happen only after a CVS command has
    completed, and you should be able to just ignore the message.
    However, if you have discovered information concerning its cause,
    please let us know as described in Dealing with bugs in CVS or
    this manual.      

Basically, I am using CVS in a chrooted environment, using SSH access
to my CVS box.  I am rather paranoid about access on these machine,
and believe in hardening the box rather than keeping up with myriad
(almost daily) security bulletins and patches, and hardening tends to
keep the amount of security worry down substantially.

About a month ago, I went through the box in question and started
zapping what I thought were inappropriate or unnecessary permissions
on files.  The chrooted CVS service was one of the first to get
serious cuts to various permissions.

Once I did this, suddenly CVS would emit the message above (then
abort) after every transaction, and if multiple transactions were
requested (such as 'cvs commit file1 file2 file3'), only the first
would be done (in that example, only the first of file1,file2,file3
which needed to be committed to the repository would be committed, and
the other changes would be ignored; retries would get the next file,
and so on).

I had the line below in my loginfo config file:
ALL (echo " "; id; echo %{sVv}; date; cat; echo "-----") >> 
$CVSROOT/CVSROOT/commitlog

It appears that CVS actually drops this as a command to the shell,
which then runs this as if it had been given -c '...' of what was in
parentheses, with STDIN redirected from the change log message.  The
echo, id, date, and cat programs were all unable to run because they
were dependent upon certain dynamic libraries which had become
non-executable due to the changes I had made to the permissions.
Limiting the commands to only static builds might have worked, but
building much statically on Linux tends to provide outlandishly sized
executables.  I made sure all of the referenced libraries were
available in /lib after the chroot, and that they were all marked
executable, and that seems to have fixed it. 

So, my research seems to point to a configuration sensitivity in CVS,
particularly on systems where dynamic linking is commonplace, as one
cause of this particular problem.  Additionally, it seems to indicate
the assertion that you can ignore the message is incorrect.

-----
[Congress] talks like George Jetson. But they support policies more appropriate 
for Fred Flinstone. -- Al Gore ENIAC 50th anniversary speech
-----
Unsolicited commercial email is not welcome under any condition.
My contact data are not to be distributed for any reason.
This message may not be accessed in any way using any service
which claims to own the information passing through it.