Bug 2362606 - chkrootkit.x86_64 0.57-8.fc42 when invoked with redirection (2>&1 >otherfilename) creates a spurious empty file called "1"
Summary: chkrootkit.x86_64 0.57-8.fc42 when invoked with redirection (2>&1 >otherfilen...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: chkrootkit
Version: 42
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-28 04:19 UTC by John Dodson
Modified: 2025-05-07 05:25 UTC (History)
1 user (show)

Fixed In Version: chkrootkit-0.58-0b.fc42 chkrootkit-0.58-0b.fc41
Clone Of:
Environment:
Last Closed: 2025-05-07 03:21:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Dodson 2025-04-28 04:19:54 UTC
chkrootkit.x86_64 0.57-8.fc42 when invoked with redirection (2>&1 >otherfilename) creates a spurious empty file called "1"

Problem occurs no matter if /usr/bin/chrootkit, /usr/sbin/chrootkit or
/usr/lib64/chkrootkit-0.57/chkrootkit are invoked.

Shell being used is /bin/bash (5.2.37(1)-release / bash.x86_64 5.2.37-1.fc42)

My invocation is usually via cron, but occurs outside of cron too.

Reproducible: Always

Steps to Reproduce:
1. /usr/lib64/chkrootkit-0.57/chkrootkit 2>&1 >chkrootkit.$DATE
2. ls -l 1
        -rw-rw----. 1 root  root       0 Apr 28 13:13 1
3. This would seem to be some kind of redirection interpretation occurring within
the shell script that does not act as expected.
Actual Results:
Empty file called "1" created that should not happen.

Expected Results:
No spurious file creation.

Additional Information:
I cannot reproduce this behaviour with any other shell scripts I use.
Placing the redirection after the destination file also does not affect the behaviour, eg.

        /usr/lib64/chkrootkit-0.57/chkrootkit >chkrootkit.$DATE 2>&1

Notably chkrootkit-0.57-8.fc42 was installed on the 24th April, & the run of it
just prior to that event (0.57-8) created the spurious file in
/usr/lib64/chkrootkit-0.57

ls -l /usr/lib64/chkrootkit-0.57/1
-rw-rw----. 1 root root      0 Apr 24 03:12 1

now it's created in the directory where the command is invoked.

So it's possible that the problem was actually in the invocation through
consolehelper, although I thought I'd proved that was not the case by invoking
/usr/lib64/chkrootkit-0.57/chkrootkit directly.

Also I started getting this PAM error when chkrootkit-0.57-8.fc42 was installed...

Apr 25 03:16:03 XXXXXX userhelper[181829]: pam_timestamp(chkrootkit:session): updated timestamp file `/var/run/pam_timestamp/root/unknown'
Apr 25 03:16:03 XXXXXX userhelper[181830]: running '/usr/lib64/chkrootkit-0.57/chkrootkit' with root privileges on behalf of 'root'

in /var/log/secure when it's run via "userhelper" but not when invoked directly
(as root from a cron job)

I assume this is when chkrootkit started using the "userhelper"/"consolehelper"(symlink)

I also now realise that the previous version was chkrootkit-0:0.57-7.fc41

ie. I was previously running FC41.

Comment 1 John Dodson 2025-04-28 12:43:31 UTC
I had not noticed the file /usr/lib64/chkrootkit-0.57/1 being created in that place
(why would I?) but now it's somewhere I don't expect it...

Comment 2 Gwyn Ciesla 2025-04-28 16:49:43 UTC
Looks like this is fixed in 0.58 b, I'll get that out.

Comment 3 Fedora Update System 2025-04-28 16:58:40 UTC
FEDORA-2025-9d30a80218 (chkrootkit-0.58-0b.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-9d30a80218

Comment 4 Fedora Update System 2025-04-28 16:58:40 UTC
FEDORA-2025-63ecf7fc82 (chkrootkit-0.58-0b.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-63ecf7fc82

Comment 5 Fedora Update System 2025-04-29 02:52:53 UTC
FEDORA-2025-9d30a80218 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-9d30a80218`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9d30a80218

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2025-04-29 03:12:20 UTC
FEDORA-2025-63ecf7fc82 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-63ecf7fc82`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-63ecf7fc82

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 John Dodson 2025-04-29 03:47:16 UTC
Thanks.
I assume you just mean the "1" file creation problem?
The pam errors are expected? or related to an additional pam problem?

Comment 8 Gwyn Ciesla 2025-04-29 14:06:05 UTC
That's correct; I can't reproduce the pam errors.

Comment 9 John Dodson 2025-04-30 03:04:07 UTC
The pam error,

        (chkrootkit:session): updated timestamp file `/var/run/pam_timestamp/root/unknown'

occurs if the symlinks (/usr/bin/chkrootkit or /usr/sbin/chkrootkit) are used from a cron script
& are generated by "userhelper".

So I guess if I continue to use the symlinks (which I'll now avoid) I'll have to report it as a bug
against userhelper.

Comment 10 Fedora Update System 2025-05-07 03:21:08 UTC
FEDORA-2025-9d30a80218 (chkrootkit-0.58-0b.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Fedora Update System 2025-05-07 03:59:25 UTC
FEDORA-2025-63ecf7fc82 (chkrootkit-0.58-0b.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 12 John Dodson 2025-05-07 05:25:08 UTC
Sorry to reopen, but...

The file /usr/lib64/chkrootkit-0.57/1 persists & is not removed
along with the dir. /usr/lib64/chkrootkit-0.57 by the install of
chkrootkit-0.58-0b

Of course it's easy to remove, if you know about it.


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