Bug 253722
| Summary: | /var/log/pm-suspend.log keeps getting the wrong selinux context | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Florian La Roche <laroche> |
| Component: | pm-utils | Assignee: | Phil Knirsch <pknirsch> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.1 | CC: | dwalsh, ebenes, jturner, rvokal |
| Target Milestone: | --- | Keywords: | Desktop |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2007-0538 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-11-07 16:44:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 238068 | ||
| Bug Blocks: | |||
|
Description
Florian La Roche
2007-08-21 14:33:07 UTC
This should take care of bz#245926. regards, Florian La Roche Pulling in flags from 245926, since this fix if required to resolve 245926. Maybe I'm being stupid, but applying that patch doesn't resolve the problem. I'll give it a shot here as well to see if it works for me. Read ya, Phil Ok. The patch fixes the issues for those entries: Aug 21 17:07:23 kfurt setroubleshoot: SELinux is preventing bash (hald_t) "getattr" access to /var/log/pm-suspend.log (var_log_t). For complete SELinux messages. run sealert -l 907ef732-54e5-4de7-8471-dc3e7509ee78 Aug 21 17:07:23 kfurt setroubleshoot: SELinux is preventing bash (hald_t) "write" to pm-suspend.log (var_log_t). For complete SELinux messages. run sealert -l 013c2899-0a62-4dd8-883b-b3d08c6a6fbc Aug 21 17:07:23 kfurt setroubleshoot: SELinux is preventing bash (hald_t) "write" to pm-suspend.log (var_log_t). For complete SELinux messages. run sealert -l 013c2899-0a62-4dd8-883b-b3d08c6a6fbc But there are 3 more that come from the 90clock hook script: Aug 21 17:10:37 kfurt setroubleshoot: SELinux is preventing 90clock (hald_t) "getattr" access to /var/run/pm-ntpd.lock (var_run_t). For complete SELinux messages. run sealert -l 0b1b84c0-7ddc-4fb5-95bf-d3fb9a62d07d Aug 21 17:10:37 kfurt setroubleshoot: SELinux is preventing /bin/touch (hald_t) "write" to pm-ntpd.lock (var_run_t). For complete SELinux messages. run sealert -l a7e98b38-1347-4d7c-aea6-7989689445fb Aug 21 17:10:37 kfurt last message repeated 3 times Aug 21 17:10:56 kfurt setroubleshoot: SELinux is preventing /bin/rm (hald_t) "unlink" access to pm-ntpd.lock (var_run_t). For complete SELinux messages. run sealert -l 030a3083-4d02-414a-ad6c-7795e99a43c0 For which we would need another selinux-policy-targeted entries (same for pm-ntpd.lock as for pm-suspend.log) as well as the restorecon line in 90clock after the touch is being done. Read ya, Phil Nvm, need proper hald_run_t for the 2nd ones ofc, but basically the same fix /var/run/pm-ntpd.lock like for /var/log/pm-suspend.log. Read ya, Phi Phil, Are you saying these files are not being created correctly ie with hald_var_run_t? Or are you saying they get bad context because the pm stuff deletes and recreates them? [root@kfurt ICE]# ls -Z /var/run/pm-ntpd.lock -rw-r--r-- root root user_u:object_r:var_run_t /var/run/pm-ntpd.lock So 90clock recreates those files which is typical for lockfiles. And that files ends up like shown above with the current -83 policy from RHEL-5.1.0. Checking the current policy only these files get hald_var_run_t flagged: [root@kfurt ICE]# grep -r hald_var_run_t /etc/selinux/targeted/contexts/ /etc/selinux/targeted//contexts/files/file_contexts:/var/run/haldaemon.pid -- system_u:object_r:hald_var_run_t:s0 /etc/selinux/targeted//contexts/files/file_contexts:/var/run/vbestate -- system_u:object_r:hald_var_run_t:s0 So seems the file_context for /var/run/pm-ntpd.lock and the appropriate restorecon in the 90clock script are missing to get rid of those, too. Read ya, Phil Just from my prospective, it appears my problems were a combination of older packages and a hosed up configuration. So I'm no longer seeing problems coming out of suspend. Appear Phil has found additional issues which need to be resolved, so I'm not monkeying with the bug state. Actually, should have added that I hacked in the functions change that phil recommended above, so that might very well be needed to fix things. Yeah, i'll review the current scripts in pm-utils in case we have missed some log/lockfile somewhere and will be building a new package today with at least the fixes mentioned here. Sounds like thats all we need according to Jay's comment #9 and comment #10. Read ya, Phil Building new packages atm, setting to modified. Read ya, Phil And it appears to be back. Fresh install of the 20070927.0 tree: selinux-policy-2.4.6-101.el5 pm-utils-0.99.3-6.el5.16 # ls -Z /var/log/pm/suspend.log -rw------- root root system_u:object_r:var_log_t /var/log/pm/suspend.log More details to follow. Reproduced on another fresh installation. /var/log/pm/suspend.log ends up with var_log_t context. What does restorecon -R -v /var/log/pm do? The problem is the directory should be created by the rpm and not created on the fly. We can not guarantee which application/script creates the directory. But if it is created via rpm, it will get the correct file context. rpm -qf /var/log/pm error: file /var/log/pm: No such file or directory [root@haring ~]# restorecon -R -v /var/log/pm restorecon reset /var/log/pm context system_u:object_r:var_log_t:s0->system_u:object_r:pmtools_log_t:s0 restorecon reset /var/log/pm/suspend.log context system_u:object_r:var_log_t:s0->system_u:object_r:pmtools_log_t:s0 [root@haring ~]# ls -Z /var/log/pm/suspend.log -rw------- root root system_u:object_r:pmtools_log_t /var/log/pm/suspend.log I'm not sure if that's the right context, but at least it's different. All that having been said, appears that we have a problem in that nothing owns /var/log/pm. Argh. Seems i forgot to package the directory: %dir /var/log/run That should fix it the problem. Quickly building a new package, please reopen the errata to NEED_RESPIN if possible. Thanks, Read ya, Phil %dir /var/log/pm ofc I've built pm-utils-0.99.3-6.el5.17 which now package %dir /var/log/pm as well for testing. Thanks, Read ya, Phil After installing 6.el5.17, the context for /var/log/pm and /var/log/pm/suspend.log appear to be correct: [root@et-10 i386]# ls -dZ /var/log/pm drwxr-xr-x root root system_u:object_r:pmtools_log_t /var/log/pm [root@et-10 i386]# ls -Z /var/log/pm -rw------- root root system_u:object_r:pmtools_log_t suspend.log Great! Thanks Jay, and thanks for catching this. Read ya, Phil An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0538.html |