| Summary: | files in /sbin depending on /usr | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Karel Volný <kvolny> |
| Component: | audit | Assignee: | Steve Grubb <sgrubb> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.1 | CC: | atodorov, jmarko, mbanas, omoris, syeghiay |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-19 16:43:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 841211, 972747 | ||
|
Description
Karel Volný
2011-04-18 15:47:16 UTC
I don't think this is too big of a problem. If the plugin fails to load, audispd will attempt to restart it next time it has an event to distribute. But moving it to /usr/sbin would be a problem because it will think the plugin does not exist and remove it from the configuration. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. (In reply to comment #2) > I don't think this is too big of a problem. If the plugin fails to load, > audispd will attempt to restart it next time it has an event to distribute. now the question is if z/OS SMF users need audit while /usr is unavailable ... > But moving it to /usr/sbin would be a problem because it will think the plugin > does not exist and remove it from the configuration. reading the man page, it says that a configfile under /etc/audisp/plugins.d should specify full path to the plugin, so adding /usr prefix there wouldn't help? Any plugin to audispd will be restarted when its needed and its dead. So, although there are links to /usr, audispd works around this problem. Why does auditspd reload plugins after one type of error and not after another? If it would reload the plugin in all cases, there would be no need to workaround it by breaking filesystem hierarchy standard. Because the one type of error means the program doesn't exist and the other means the child program quit. And why is "doesn't exist" considered unrecoverable while "doesn't start" is not? I'm still looking for some justification for breaking FSH... Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
*** Bug 754109 has been marked as a duplicate of this bug. *** Did we want to use this bug as a tracker for moving the libraries? Or did you just want to document this per solution #3 in the problem description? Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Ondřej, just a question to your bug #754109 - does the sharedlib test still fail? if there's no interest in fixing this, I guess we could move on and ask for exception *** Bug 905394 has been marked as a duplicate of this bug. *** (In reply to Karel Volný from comment #13) > Ondřej, just a question to your bug #754109 - does the sharedlib test still > fail? > > if there's no interest in fixing this, I guess we could move on and ask for > exception Sorry for a delayed answer. bug #754109 was fixed, an exception for audispd-zos-remote was added and sharedlib test is not failing anymore. This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. Closing since an exception was added. |