Bug 1325620 - Runtime permission changes of /mnt vs packaged content.
Summary: Runtime permission changes of /mnt vs packaged content.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: filesystem
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-10 01:59 UTC by Steven Haigh
Modified: 2016-04-13 19:18 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-13 19:18:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.