Bug 1406254

We see this. On Desktops it causes chrome to fail, was how we first noticed it:

shm_open() failed: Permission denied [20860:20860:1109/094549:ERROR:shared_memory_posix.cc(290)] Creating shared memory in /dev/shm/.com.google.Chrome.0RxfmG failed: Permission denied [20860:20860:1109/094549:ERROR:shared_memory_posix.cc(293)] Unable to access(W_OK|X_OK) /dev/shm: Permission denied [20860:20860:1109/094549:FATAL:shared_memory_posix.cc(295)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix. Abort (core dumped) 

But more surprised more people haven't seen or reported this issue, you'd think a lot of software would rely on this. It would seem to be quite a significant issue.

Colin: the bug likely doesn't affect all systems; it comes down to whether /dev/shm is in /run/initramfs/state or not. dracut might put it there, or it might not; there are both legitimate reasons and at least one bug which caused it to be placed there when it wasn't really needed, which was the case we ran into with Fedora UEFI live installs.

The immediate fix is to change initscripts as it was changed in F25, so that when /dev/shm is synced from /run/initramfs/state to the 'real' root, its permissions are correct. But you may also want to look into why /dev/shm is showing up in /run/initramfs/state for you in the first place and figure if it's a legitimate reason or a bug in dracut. If you're using FCoE, for instance, it's there for a legitimate reason.

Interesting, we don't use FCoE, but some packages may have crept onto some machines. But I can't see which one would trigger this. 

I thought maybe fcoe-utils but I see anaconda-core needs this, so I can't remove that one.

if you're interested to figure it out you kinda have to dig into the dracut source, which is...a bunch of shell scripts with a whole bunch of their own conventions. it's so much fun!

From the original comment on this bug it sounds a bit like perhaps an EL7 update did something inadvisable, but I don't work on RHEL so I haven't looked at it in detail. You might want to look at that /usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh file, though, and see if it looks like it might be the culprit for you too. If it causes the dracut 'lldpad' module to be included, then it's likely the culprit - any path which causes that module to be included will result in /dev/shm being in /run/initramfs/state .

I don't know how 'conditional' the impact is (i.e. whether any EL 7 install with that file will have the problem, or if there's some kind of test in the file which means only certain systems will be affected). Supreet probably would have more info. It sounds like this may be similar to the case in Fedora, where it would affect any UEFI install if all the packages needed by the dracut 'fcoe' module are installed.

Thanks

I think the  /usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh is the cuprit as /dev/shm/ contains lldpad.state. 

But, I wonder if simply having an UEFI system is enough to trigger this chain of events?

If RHEL 7's current dracut does not have this issue fixed:

https://github.com/dracutdevs/dracut/issues/139

then yes, just having that hook on a UEFI install with all the packages required for the dracut fcoe module would likely trigger it.

It sounds like RHEL 7 just needs the same fixes we applied to Fedora: firstly fix initscripts to set the mode correctly when transferring the directory, and secondly fix dracut not to enable the fcoe module on any UEFI system.

This is a regression as this doesn't happen in 7.2. Given this and that there is a Fedora fix already, is a patch on the way, or do we need to open a support case?

(In reply to Colin Simpson from comment #8)
> This is a regression as this doesn't happen in 7.2. Given this and that
> there is a Fedora fix already, is a patch on the way, or do we need to open
> a support case?

Please open a support case.

Opening the support case leads to a KB article that suggests a workaround:

https://access.redhat.com/solutions/2759321

(this also suggests another bug report on this issue that is private). 

But this KB Article is WRONG in scope. It effects *ALL* UEFI systems and not just ones that have FCoE, due the the FCoE modules being included on any UEFI system.  But I guess the workaround should work.

Patch from Fedora could be easily backported.

*** Bug 1405188 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2286