Bug 1325620

Summary: Runtime permission changes of /mnt vs packaged content.
Product: Red Hat Enterprise Linux 7 Reporter: Steven Haigh <netwiz>
Component: filesystemAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: csieh, misterbonnie, netwiz, riehecky
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: 2016-04-13 19:18:28 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:

Description Steven Haigh 2016-04-10 01:59:08 UTC
When using 'yum verify' to audit the running system, it seems the permissions set in the RPM for /mnt differ from what the system sets up at runtime.

This leads to the following audit error when using 'yum verify':

filesystem.x86_64 : The basic directory layout for a Linux system
    File: /mnt
        Problem:  mode does not match
        Current:  user:-rx, group:-rx, other:-rx
        Original: user:wrx, group:-rx, other:-rx

Please check if this is intentional, and possibly update the permissions in the package to match what the system should actually have to allow passing of an audit via 'yum verify'.

Comment 2 Ondrej Vasik 2016-04-13 14:59:26 UTC
drwxr-xr-x. root root are expected permissions for the /mnt . It looks something modified the permissions on your system - but this is not a bug in filesystem package. Please provide more information why you think this is a bug in filesystem package.

Comment 3 Steven Haigh 2016-04-13 15:13:19 UTC
Sorry, I'd like to apologise for this one.

I did a whole heap of verification on multiple systems on a few packages that did this - then when I was gathering the information, I picked the top two on the last system I checked and failed to notice that this package was not common between machines.

While there are multiple offending packages, it seemed I picked this one in error. BZ 1325621 is actually a correct example.

As such, this can be closed. I'll attempt to triple check these across multiple machines before reporting the next one.

Comment 4 Ondrej Vasik 2016-04-13 19:18:28 UTC
Thanks for clarification. Closing.