Bug 964208
| Summary: | htop trying to access proc io stats as normal user | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Gary Anderson <gary.p.anderson> |
| Component: | htop | Assignee: | Mukundan Ragavan <nonamedotc> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | el5 | CC: | admiller, gajownik |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | htop-1.0.3-1.el5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-05 22:36:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hi Gary, thanks for your bug report. I prepared a patch and sent it to the upstream developer for the review. Hopefully it will be fixed in the next htop version. Just a quick question: latest htop binary tries to access /proc/*/task/*/io or /proc/*/io? htop-1.0.3-1.el5 has been submitted as an update to Fedora EPEL 5. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6cc3eabd11 htop-1.0.3-1.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'yum --enablerepo=epel-testing update htop' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6cc3eabd11 htop-1.0.3-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: htop-0.8.3-1.el5.x86_64 attempts to access the /proc/*/task/*/io file as a normal user. In RHEL5 this file is owned by root, with a mode of 0400. The attempt throws an error -13 ("access denied") to the audit subsystem for each and every access attempt, literally thousands per second. If the auditd is running and access denied events are being logged, this could potentially fill the filesystem in a short time. On a busy system it has been seen that the audit subsystem will overrun a buffer of 8192 (default for stig.rules) with these audit events, and if the failure mode for audit is set to 2 ("PANIC", which is again default in stig.rules), the system will kernel panic on this event. Version-Release number of selected component (if applicable): 0.8.3-1.el5 How reproducible: When the htop is run as a normal user on a busy system running file access denial auditing. Steps to Reproduce: 1. Activate the auditd subsystem with access denied events being logged 2. Run htop as a normal user 3. create an appreciable amount of activity on a system (e.g. database, httpd, etc.) Actual results: Many access denied events per second being logged from the htop process access attempts to the proc io file for each process. Expected results: when run as a normal user, htop not attempting to access a file which is by default not accessible by normal users in a RHEL5 system. Additional info: This may be a somewhat unique configuration, but still something to think about as many systems use the NSA RHEL5 Hardening Guide suggestions (http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), of which section 2.6.2.4.8, "Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)", details the auditctl commands to record these events. I am sure there are similar recommendations in the security community.