Bug 437901 - head terminated by signal 13
head terminated by signal 13
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: chkrootkit (Show other bugs)
8
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Michael Schwendt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-17 20:08 EDT by Adrian
Modified: 2008-03-19 05:47 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-19 05:47:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
chkrootkit output (75.10 KB, text/plain)
2008-03-17 20:11 EDT, Adrian
no flags Details

  None (edit)
Description Adrian 2008-03-17 20:08:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Fedora/2.0.0.12-1.fc8 Firefox/2.0.0.12

Description of problem:
When I run chkrootkit, the following message gets displayed (multiple times):
/usr/bin/find: head terminated by signal 13

Version-Release number of selected component (if applicable):
chkrootkit-0.48-2.fc8

How reproducible:
Always


Steps to Reproduce:
1. #chkrootkit

Actual Results:
chkrootkit starts performing checks and searches, the error message appears repeatedly and then it continues with the remaining checks.

Expected Results:
No error messages (?)

Additional info:
Comment 1 Adrian 2008-03-17 20:11:13 EDT
Created attachment 298320 [details]
chkrootkit output
Comment 2 Michael Schwendt 2008-03-18 01:34:14 EDT
Please run as "root":

/usr/bin/find /tmp /var/tmp  -type f -exec head -1 {} \; | grep php 2> /dev/null

What do you get?


Is this with SELinux in enforcing mode?
If so, run it again with SELinux in permissive mode.
Comment 3 Adrian 2008-03-18 08:06:53 EDT
When I run "/usr/bin/find /tmp /var/tmp  -type f -exec head -1 {} \; | grep php
2> /dev/null" as root and in enforcing mode, I get the following:

Binary file (standard input) matches
/usr/bin/find: head terminated by signal 13
/usr/bin/find: head terminated by signal 13
...
... (repeated 1611 times)

I get the exact same output when running it in permissive mode. I checked the
gui (system-config-selinux) and performed a cat /selinux/enforce, which gave me
0, to make sure that I was in permissive mode.

I would be glad to provide any further information that you may require.
Comment 4 Michael Schwendt 2008-03-18 09:46:17 EDT
Please show the output of

  rpm -V grep

and

  rpm -q grep
Comment 5 Adrian 2008-03-18 09:54:34 EDT
rpm -V grep
(produces no output)

rpm -q grep
grep-2.5.1-57.fc7
Comment 6 Michael Schwendt 2008-03-18 10:17:02 EDT
So, I can only reproduce it if /bin/grep is missing or damaged
as in
 
  find /tmp /var/tmp -type f -exec head -1 {} \; | fubar

and that is not a bug in chkrootkit. Does

  find /tmp /var/tmp -type f -exec head -1 {} \; | /bin/grep php

work for you?

Also, what files do you have in the tmp directories, that they
break a find->head->grep pipe?
Comment 7 Adrian 2008-03-18 10:50:38 EDT
I'm beginning to think that the problem must be with whatever I have in my /tmp
and /var/tmp directories. I took a risk (I think?) and deleted everything form
/var/tmp. When I ran "find /tmp /var/tmp -type f -exec head -1 {} \; | /bin/grep
php", the error message was repeated 1104 times. It was 1611 times before.
Unfortunately, I have no idea what caused those "strange" files to end up in my
/tmp directories.
Comment 8 Adrian 2008-03-18 10:55:54 EDT
Sorry, I clicked "Save Changes" too quickly. A Google search prompted me to file
a bug report (http://www.webhostingtalk.com/archive/index.php/t-664965.html).
There was not really any useful information in that particular forum. It's just
that someone else seems to have had the same problem.
Comment 9 Michael Schwendt 2008-03-18 11:10:32 EDT
It's just that this check is NEW in chkrootkit 0.48, but as you
can see the pipe breaks also in a normal shell outside chkrootkit
(Signal 13 is "Broken pipe: write to pipe with no readers").

Can you find one of the files that breaks like this, for example
with

  find /tmp /var/tmp -type f

and make it available in some place?
Comment 10 Adrian 2008-03-18 13:11:54 EDT
After a lot of trial and error, I think I may have found the culprit. I moved a
directory called pybackpack.cdimage/ out of /tmp/ - and the problem has gone away.

It seems that pybackpack-0.5.1-2.fc8 wrote something to /tmp/ that broke the
find->head->grep pipe.

Should I still attach the contents of the pybackpack.cdimage directory?
Comment 11 Michael Schwendt 2008-03-18 14:07:04 EDT
No need to. It's whitespace and other characters that are the
culprit.
Comment 12 Michael Schwendt 2008-03-19 05:47:21 EDT
https://admin.fedoraproject.org/updates/F8/pending/chkrootkit-0.48-6.fc8

Temporary solution is to remove the "suspect PHP files" check.
It would be possible to convert the find->exec->head->... line
to find->print0->xargs->head->... (which is what I've submitted
upstream when reporting this) to make it work with special file
names. But the entire check is broken by design, because any
non-text file contents confuse the results of the grep if they
match. That's easy to reproduce with test data files. For instance,
many audio data files contain a byte-sequence "php" near the
beginning. Out of coincidence. And grep treats text and binary
files differently, but here everything from head -1 is concatenated
into a single input stream, therefore any binary fragment in the
input would make grep believe everything is binary. In that case,
it would print 

  Binary file (standard input) matches

only once. Further, on matches in the 2nd half of the check, not file
names are printed, but file contents. That can't be what the check
is supposed to achieve.

Closing as RAWHIDE because test updates for F7, F8 and F9 development
are pending. Thanks for taking the time to report report this.

Note You need to log in before you can comment on or make changes to this bug.