Bug 1066591
| Summary: | Adjust the /sys permissions to match kernel (should be 555) + wrong "/" permissions (should be 555) | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Karel Volný <kvolny> | |
| Component: | filesystem | Assignee: | Ondrej Vasik <ovasik> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jan Ščotka <jscotka> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.0 | CC: | jmarko, jscotka, kvolny, ovasik | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | filesystem-3.2-17.el7 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1149374 (view as bug list) | Environment: | ||
| Last Closed: | 2014-06-13 11:49:40 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1149374 | |||
|
Description
Karel Volný
2014-02-18 16:54:53 UTC
If package verification fails, it means some package changed the ownership after installation of the filesystem rpm. For the /sys , I believe https://bugzilla.redhat.com/show_bug.cgi?id=1037862 is the reason - kernel changed the permissions even for RHEL-7. Let's fix that one. For "/" please do some investigation what is touching that dir. Ownership and mode in filesystem package is correct, however I can't force the other packages to not modify it later. As some pointers - does it occur even in minimal installation? Setting the blocker flag, Karel, please answer the questions and provide more information - otherwise I can't do much with it (555 for /sys is the thing I should change, but for / , I don't know what touches the root after the filesystem package installation - in the rpm it seems to be correct. (In reply to Ondrej Vasik from comment #1) > For "/" please do some investigation what is touching that dir. Ownership > and mode in filesystem package is correct, however I can't force the other > packages to not modify it later. jmarko is working on improved version of the tool that watches changes between tests, so maybe we'll be able to catch something ... > As some pointers - does it occur even in minimal installation? I've just scheduled Beaker job with this one test separately (job id 605532) however, we're running out of ideas, how to debug ... I believe it is not a packaging conflict, as nothing else seems to own / (but I'm not good in repoquery magic :-)) I was thinḱing about 'auditctl -w /' but man says: "You cannot insert a watch to the top level directory. This is prohibited by the kernel." ... any other ideas? (In reply to Karel Volný from comment #4) > I've just scheduled Beaker job with this one test separately (job id 605532) resubmitted as job 605585 because Beaker had old version of the test for some reason (previous tagging failed?) Package ownership is not necessary - I don't think some other package actually owns the / - but can do some black magic in %post/%postun scriptlets - some copying with parents or something like that - I actually did something like this with rootfiles in Fedora and /root, recently - so it might be completely unintentional. Anyway - if you want to fix /sys permissions for 7.0 and defer the "/" issue investigation for 7.1, please grant the qa_ack ... (In reply to Karel Volný from comment #5) > resubmitted as job 605585 because Beaker had old version of the test for > some reason (previous tagging failed?) well, so it failed too ... (In reply to Ondrej Vasik from comment #6) > Anyway - if you want to fix /sys permissions for 7.0 and defer the "/" issue > investigation for 7.1, please grant the qa_ack ... ok, let's do at least /sys and investigate / later This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |