Description of problem: I'm getting continual selinux alerts about /dev/shm/lldpad.state since upgrading to Fedora 23. Running through the recommended steps suggested by sealert does not solve the problem. Version-Release number of selected component (if applicable): Fedora 23, latest release. The following is displayed in the system journal: failed to retrieve rpm info for /dev/shm/lldpad.state SELinux is preventing mdadm from getattr access on the file /dev/shm/lldpad.state. For complete SELinux messages. run sealert -l a7110687-2ca5-49cc-8d57-4fec455834a3 sealert suggests running: /sbin/restorecon -v /dev/shm/lldpad.state However doing so does not persist with a reboot. One other thing to mention is that after upgrading from F22 to 23, I had to set all the selinux booleans from scratch - I don't know if that's related but it seems like something you shouldn't have to do. I thought maybe a full relabelling might do the trick i.e. "touch /.autorelabel ", but no dice.
Hi, Could you attach outputs of: # ls -Z /dev/shm/lldpad.state # sealert -l a7110687-2ca5-49cc-8d57-4fec455834a3 Thank you!
Sure no problem. # ls -Z /dev/shm/lldpad.state system_u:object_r:tmpfs_t:s0 /dev/shm/lldpad.state # sealert -l 97931df8-71c8-47e7-b1f3-ab1d6017f6a0 SELinux is preventing systemd-logind from getattr access on the file /dev/shm/lldpad.state. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /dev/shm/lldpad.state default label should be lldpad_tmpfs_t. Then you can run restorecon. Do # /sbin/restorecon -v /dev/shm/lldpad.state ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that systemd-logind should be allowed getattr access on the lldpad.state file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-logind /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:systemd_logind_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects /dev/shm/lldpad.state [ file ] Source systemd-logind Source Path systemd-logind Port <Unknown> Host hell-serv Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-154.fc23.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hell-serv Platform Linux hell-serv 4.2.6-300.fc23.x86_64 #1 SMP Tue Nov 10 19:32:21 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-11-23 12:56:19 GMT Last Seen 2015-11-23 12:56:19 GMT Local ID 97931df8-71c8-47e7-b1f3-ab1d6017f6a0 Raw Audit Messages type=AVC msg=audit(1448283379.595:587): avc: denied { getattr } for pid=927 comm="systemd-logind" path="/dev/shm/lldpad.state" dev="tmpfs" ino=1315 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0 Hash: systemd-logind,systemd_logind_t,tmpfs_t,file,getattr As mentioned before if I run: # /sbin/restorecon -v /dev/shm/lldpad.state Then # ls -Z /dev/shm/lldpad.state Becomes: system_u:object_r:lldpad_tmpfs_t:s0 /dev/shm/lldpad.state But it reverts back after a reboot.
Also I should mention that I'm getting these messages every minute or so: 15:39 AVC Message for setroubleshoot, dropping message sedispatch 15:39 failed to get filesystem list from rpm setroubleshoot Not sure if that's related.
This is still an issue if anyone cares.
Same problem with Fedora 22.
*** Bug 1286167 has been marked as a duplicate of this bug. ***
Selinux alerts caused by the wrong context on /dev/shm/lldpad.state were occurring on one of my systems running Fedora 22. Shared memory files are not persistent. They must be re-created after a reboot. I suspected whatever was creating /dev/shm/lldpad.state was simply creating it with the wrong context. To stop the alerts while I looked into the problem I used the following service file. ------- [Unit] Description=Restore Context lldpad.state After=syslog.target network.target lldpad.service [Service] ExecStart=/usr/sbin/restorecon /dev/shm/lldpad.state [Install] WantedBy=multi-user.target ------- I placed the service file in /etc/systemd/system and enabled it but I continued to get one alert after a bootup. I disabled the lldpad.service and continued to get the alert after bootup from an access by mdadm. I removed fcoe.utils. FCOE devices use LLDP. I continued to get one alert after bootup. I then suspected the problem involved the boot process. In the CentOS git repo I found a patch that contained the following: +if [ -e /var/run/lldpad.pid ]; then + lldpad -k + mkdir -m 0755 -p /run/initramfs/state/dev/shm + cp /dev/shm/lldpad.state /run/initramfs/state/dev/shm/ > /dev/null 2>&1 + echo "files /dev/shm/lldpad.state" >> /run/initramfs/rwtab See https://git.centos.org/blob/!rpms!dracut.git/64b87c0c955a171fd6b5b504708fe42f0da74f54/SOURCES!0308-fcoe-cleanup-lldpad.patch;jsessionid=8e9vx206njy2jefj0xk73fsa I cannot access the bug referenced in the patch on Redhat Bugzillia (You are not authorized to access bug #1246217.) I saved my current initramfs image and then ran dracut. There was no alert after the reboot because /dev/shm/lldpad.state was not created. I have Fedora 23 systems. They do not behave the same as the Fedora 22 system. The file /dev/shm/lldpad.state is created with the proper context when the lldpad.service is enabled on Fedora 23. On Fedora 23 Workstation no file is created if the lldpad.service is disabled. On Fedora 22 the lldpad.state file is created with the wrong context at bootup when the initramfs image is made with the fcoe.utils package installed. If you remove the package and make the initramfs image the lldpad.state file is not created at bootup. If you re-add the fcoe.utils package and reboot with the initramfs image made when the fcoe.utils package is removed, no file is created at bootup. (Note, with dnf you cannot add fcoe.utils you must add anaconda; whereas, you can remove fcoe.utils which also removes anaconda.) If you enable the lldpad.service and boot the lldpad.state file is created with the proper context when the initramfs image was made with no fcoe.utils installed. There is a failure to set the proper context of /dev/shm/lldpad.state at bootup with an initramfs image made with fcoe.utils installed on Fedora 22. There may be some useful information in the restricted bug. I speculate to get FOCE to work properly it must have LLDP available early in the boot process and is related to causing this bug.
See Comment 8. Additional information... ---- - cleanup lldpad cleanly to help out in state transition from initramfs Resolves: rhbz#1246217 ----- $ cat /usr/lib/dracut/modules.d/95fcoe/lldpad.sh #!/bin/bash # Note lldpad will stay running after switchroot, the system initscripts # are to kill it and start a new lldpad to take over. Data is transfered # between the 2 using a shm segment lldpad -d # wait for lldpad to be ready i=0 while [ $i -lt 60 ]; do lldptool -p && break info "Waiting for lldpad to be ready" sleep 1 i=$(($i+1)) done ---- diff of lsinitrd output for initramfs files made with and without fcore.utils. bogwan@valkyrie2:/boot $ diff /tmp/bad.txt /tmp/gud.txt | grep lldpad < -rw-r--r-- 1 root root 363 Jan 31 2015 usr/lib/dracut/hooks/pre-trigger/03-lldpad.sh < -rwxr-xr-x 1 root root 416528 Dec 22 08:54 usr/sbin/lldpad < drwxr-xr-x 2 root root 0 Dec 22 08:54 var/lib/lldpad bogwan@valkyrie2:/boot ---- The difference in the initramfs files is if fcoe.utils is installed, lldpad is started in the initramfs. Apparently the shared memory file is created with an incorrect context at that time in Fedora 22.
I think I understand the problem after a bit of reading. From the lldpad man page: "If lldpad has dropped back to legacy DCBX mode for a given interface and the daemon is stopped and restarted, the legacy DCBX mode for that interface will be used instead of starting out in IEEE DCBX mode." The daemon lldpad is started in initramfs to take advantage of this behavior. The rub is that when the shared memory file is created the context is not changed from system_u:object_r:tmpfs_t:s0 to system_u:object_r:lldpad_tmpfs_t:s0. There is no restorecon in the initramfs to make the change and there are probably other resources needed. I think systemd executes load_policy but may not do it until after lldpad is run which could explain why the context is wrong for /dev/shm/lldpad.state. In any case the shared memory is created and lldpad is killed and normally restarted by lldpad.service. My statements could very well be wrong but if they are close to correct there is a simple workaround for the problem. Change /usr/lib/systemd/system/lldpad.service by adding: ExecStartPre=/usr/sbin/restorecon /dev/shm/lldpad.state ------------- [Unit] Description=Link Layer Discovery Protocol Agent Daemon. After=syslog.target network.target [Service] Type=simple ExecStartPre=/usr/sbin/restorecon /dev/shm/lldpad.state ExecStart=/usr/sbin/lldpad -t ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target Also=lldpad.socket -------------- The lldpad service must be enabled for the context to be corrected. There is one small problem not corrected. mdadm will create one alert at bootup. It must be run in initramfs to handle the case where root is on an mdraid device. To fix it all you need to run restorecon in initramfs which is probably the right thing to do.
(In reply to Norman Smith from comment #10) > I think I understand the problem after a bit of reading. > > From the lldpad man page: > > "If lldpad has dropped back to legacy DCBX mode for a given interface and > the daemon is stopped and restarted, the legacy DCBX mode for that interface > will be used instead of starting out in IEEE DCBX mode." > > The daemon lldpad is started in initramfs to take advantage of this > behavior. The rub is that when the shared memory file is created the > context is not changed from system_u:object_r:tmpfs_t:s0 to > system_u:object_r:lldpad_tmpfs_t:s0. There is no restorecon in the > initramfs to make the change and there are probably other resources needed. > I think systemd executes load_policy but may not do it until after lldpad is > run which could explain why the context is wrong for /dev/shm/lldpad.state. > In any case the shared memory is created and lldpad is killed and normally > restarted by lldpad.service. > > My statements could very well be wrong but if they are close to correct > there is a simple workaround for the problem. > > Change /usr/lib/systemd/system/lldpad.service by adding: > > ExecStartPre=/usr/sbin/restorecon /dev/shm/lldpad.state > > ------------- > [Unit] > Description=Link Layer Discovery Protocol Agent Daemon. > After=syslog.target network.target > > [Service] > Type=simple > ExecStartPre=/usr/sbin/restorecon /dev/shm/lldpad.state > ExecStart=/usr/sbin/lldpad -t > ExecReload=/bin/kill -HUP $MAINPID > > [Install] > WantedBy=multi-user.target > Also=lldpad.socket > -------------- > > The lldpad service must be enabled for the context to be corrected. > > There is one small problem not corrected. mdadm will create one alert at > bootup. It must be run in initramfs to handle the case where root is on an > mdraid device. To fix it all you need to run restorecon in initramfs which > is probably the right thing to do. Nice idea, but the context remains as system_u:object_r:lldpad_tmpfs_t:s0
(in reply to Dominic Robinson from comment #11) > Nice idea, but the context remains as system_u:object_r:lldpad_tmpfs_t:s0 I don't understand your comment. system_u:object_r:lldpad_tmpfs_t:s0 is the proper context. But I am glad you made the comment because it started me thinking about the problem again. I found a way to stop the alerts from mdadm and lldpad. I have not seen any for systemd-logind but the workaround should handle it too. /dev/shm/lldpad.state is a shared memory file. The file exists in memory.The file does not persist across reboots. It is created by lldpad which is run at boot time from the initramfs. The reason /dev/shm/lldpad.state has a context of system_u:object_r:tmpfs_t:s0 is the file does not exist at boot time. It inherits the context of its parent directory when it is created by the first run of lldpad. $ ls -dZ /dev/shm system_u:object_r:tmpfs_t:s0 /dev/shm Installing the following service file (rclldpad.service) in /etc/systemd/system and enabling the service will correct the context of /dev/shm/lldpad.state. -------------- [Unit] Description=Restore Context lldpad.state Before=mdmonitor.service systemd-logind.service ConditionPathExists=/dev/shm/lldpad.state [Service] ExecStart=-/usr/sbin/restorecon /dev/shm/lldpad.state [Install] WantedBy=multi-user.target ------------- There is no need for changes in the initramfs. The above service file stopped all alerts caused by wrong context for /dev/shm/lldpad.state on my Fedora 22 system. If there is a better way I am sure someone at Fedora will provide it.
(In reply to Norman Smith from comment #12) > (in reply to Dominic Robinson from comment #11) > > > Nice idea, but the context remains as system_u:object_r:lldpad_tmpfs_t:s0 > > I don't understand your comment. system_u:object_r:lldpad_tmpfs_t:s0 is the > proper context. But I am glad you made the comment because it started me > thinking about the problem again. I found a way to stop the alerts from > mdadm and lldpad. I have not seen any for systemd-logind but the workaround > should handle it too. > > /dev/shm/lldpad.state is a shared memory file. The file exists in memory.The > file does not persist across reboots. > > It is created by lldpad which is run at boot time from the initramfs. > > The reason /dev/shm/lldpad.state has a context of > system_u:object_r:tmpfs_t:s0 is the file does not exist at boot time. It > inherits the context of its parent directory when it is created by the first > run of lldpad. > > $ ls -dZ /dev/shm > system_u:object_r:tmpfs_t:s0 /dev/shm > > Installing the following service file (rclldpad.service) in > /etc/systemd/system and enabling the service will correct the context of > /dev/shm/lldpad.state. > > -------------- > [Unit] > Description=Restore Context lldpad.state > Before=mdmonitor.service systemd-logind.service > ConditionPathExists=/dev/shm/lldpad.state > > [Service] > ExecStart=-/usr/sbin/restorecon /dev/shm/lldpad.state > > [Install] > WantedBy=multi-user.target > ------------- > > There is no need for changes in the initramfs. The above service file > stopped all alerts caused by wrong context for /dev/shm/lldpad.state on my > Fedora 22 system. > > If there is a better way I am sure someone at Fedora will provide it. Yes sorry got those the wrong way round. However your latest suggestion has worked for me as well - on F23. Thank you!
*** Bug 1297142 has been marked as a duplicate of this bug. ***
*** Bug 1300825 has been marked as a duplicate of this bug. ***
Description of problem: I've encountered this after having logged in to a KDE Plasma session. Version-Release number of selected component: selinux-policy-3.13.1-171.fc24.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.5.0-0.rc5.git0.1.fc24.x86_64 type: libreport
*** Bug 1317299 has been marked as a duplicate of this bug. ***
Hi lldpad folks, Is it possible to run "/usr/sbin/restorecon /dev/shm/lldpad.state" in "ExecStart" in lldpad service file? Thank you!
@Lukas tried that >> [Unit] Description=Link Layer Discovery Protocol Agent Daemon. After=syslog.target network.target [Service] Type=simple ExecStart=/usr/sbin/restorecon /dev/shm/lldpad.state && /usr/sbin/lldpad -t ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target Also=lldpad.socket Didn't make a difference.
The switch to POSIX shm was done specifically to make restorecon possible, and in rhel7 that was handled with an update to the dracut module using /run/initramfs/rwtab. It looks like fedora dracut needs the same update as bz 1246217
Great, Thank you, Chris for help. Is it possible to add cleanup dracut hooks also to Fedora? Thank you.
(In reply to Dominic Robinson from comment #19) > @Lukas tried that >> > > [Unit] > Description=Link Layer Discovery Protocol Agent Daemon. > After=syslog.target network.target > > [Service] > Type=simple > ExecStart=/usr/sbin/restorecon /dev/shm/lldpad.state && /usr/sbin/lldpad -t > ExecReload=/bin/kill -HUP $MAINPID > > [Install] > WantedBy=multi-user.target > Also=lldpad.socket > > Didn't make a difference. I don't think "&&" works. systemd is not bash. You better do: ExecStartPre=/usr/sbin/restorecon /dev/shm/lldpad.state ExecStart=/usr/sbin/lldpad -t $ man systemd.service ExecStart= […] Note that this setting does not directly support shell command lines. If shell command lines are to be used, they need to be passed explicitly to a shell implementation of some kind. […] ExecStartPre=, ExecStartPost= Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially. If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.
(In reply to Chris Leech from comment #20) > The switch to POSIX shm was done specifically to make restorecon possible, > and in rhel7 that was handled with an update to the dracut module using > /run/initramfs/rwtab. > > It looks like fedora dracut needs the same update as bz 1246217 Why do we have to copy those files around anyway? systemd is relabeling files in /run and /dev already. It is missing mountpoints in /dev (/dev/shm and /dev/pts) though. https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L377 We can fix this in systemd, if you want.
(In reply to Harald Hoyer from comment #23) > (In reply to Chris Leech from comment #20) > > The switch to POSIX shm was done specifically to make restorecon possible, > > and in rhel7 that was handled with an update to the dracut module using > > /run/initramfs/rwtab. > > > > It looks like fedora dracut needs the same update as bz 1246217 > > Why do we have to copy those files around anyway? > > systemd is relabeling files in /run and /dev already. > It is missing mountpoints in /dev (/dev/shm and /dev/pts) though. > > https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L377 > > We can fix this in systemd, if you want. https://github.com/systemd/systemd/pull/3039
This is a problem on Fedora 24 with systemd-229-7.fc24.x86_64 and selinux-policy-3.13.1-189.fc24.noarch File a new bug? type=AVC msg=audit(1464559487.291:350): avc: denied { getattr } for pid=820 comm="systemd-logind" path="/dev/shm/lldpad.state" dev="tmpfs" ino=15392 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0
Description of problem: This happened on a default KDE install, probably during switching users. Version-Release number of selected component: selinux-policy-3.13.1-189.fc24.noarch Additional info: reporter: libreport-2.7.1 hashmarkername: setroubleshoot kernel: 4.5.5-300.fc24.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
Description of problem: install and login into cinnamon Version-Release number of selected component: selinux-policy-3.13.1-193.fc25.noarch Additional info: reporter: libreport-2.7.1 hashmarkername: setroubleshoot kernel: 4.6.0-1.fc25.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
Proposed as a Blocker for 24-final by Fedora user chrismurphy using the blocker tracking app because: There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop.
Description of problem: Appeared right after the login on the desktop Version-Release number of selected component: selinux-policy-3.13.1-189.fc24.noarch Additional info: reporter: libreport-2.7.1 hashmarkername: setroubleshoot kernel: 4.5.5-300.fc24.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
I tried booting the 2016-05-31 x86_64 KDE live on both a VM and bare metal and didn't see this - I didn't see a notification, nor do I see a denial in ausearch. Has anyone seen a *desktop notification* for this, in the course of just doing a boot / install / first boot cycle, in KDE or GNOME? Do we have any precise reproduction scenario for it?
I tried to reproduce the issue from comment 26, but I was not successful. Also, I believe I've previously seen a desktop notification just because I installed setroubleshoot manually (not present by default in KDE).
Since there is no visible *desktop* notification of the avc denial (in gnome shell in my case), I agree with adamw that this does not meet the criterion requirement. -1 blocker.
fedora update 24 ---> 25 { ksrl disabled: kasrl not on cmdline ACPI: _PSW execution failed unable to selinux security context of /dev/shmlldpad.state: permission denied } on what does not react, the above errors are written 2-3 times, below the text about starting system services, but no result.
I attempted to recreate this bug on F24_KDE_20160531n0 and could not reproduce the bug. However, if the bug appears like Zdenek reported in comment 29 (notification appearing after boot), I vote +1 blocker as it violates the following Final Blocker criteria: [1] "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop." If we determine the bug was due to an odd configuration (hardware/software) we can use the following to remove the blocker classification (See the "Exclusions" pull-down at [1]): "Notifications that only happen on unusual configurations are excluded." [1] https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#SELinux_and_crash_notifications
This bug was discussed at the 2016-06-06 blocker review meeting [1] and determined to be a RejectedBlocker as it is hard to tell whether or not there is an automatic desktop notification displayed when this bug occurs and regardless, there are no significant practical consequences to this bug. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-06-06/f24-blocker-review.2016-06-06-16.00.txt
I have encountered an error while upgrading from 24 to 25, I enabled new repo, after update process I did touch /.autorelabel and after reboot I had kernel 4.7..., and as a result I've got: ACPI: _PSW exectuion failed, kаsrl disabled: kaslr not on cmdline, and unable to selinux security context of /dev/shmlldpad.state: permission denied After which, services start up and everything freezes. I tried chrooting into system and disabling selinux which allows me to login into system, but problem with acpi and colour correction doesn't allow me to work properly yet. I am not sure however, how to write a bug report on it yet, because I lack any concrete information needed. ACPI only has beforementioned error message and about colour correction I have nothing at all. --sysinfo http://paste.fedoraproject.org/375824/53042961
Still happens on Fedora 24. Since I have RAID array SELinux alert happens when using some disk utilities like gparted. Following reverts after reboot. $ sudo restorecon -v /dev/shm/lldpad.state restorecon reset /dev/shm/lldpad.state context system_u:object_r:tmpfs_t:s0->system_u:object_r:lldpad_tmpfs_t:s0
So what I think was a fix for this went into initscripts 9.67: https://git.fedorahosted.org/cgit/initscripts.git/commit/?id=481aa46e866fc6d99d954d9cf9cd2ab1898e0f84 but Fedora 24 doesn't have that initscripts, and the fix hasn't been backported. Lukas, am I correct that that fix is for this issue? Could we backport it to F24?
For anyone who may have used the workaround in comment 12, the "better way" is in comment 38. Don't forget to remove that service file. In Fedora 24 I removed the service file described in comment 12. I rebooted and the context was wrong. I added the F option to /lib/systemd/fedora-import-state as shown in the commit referenced in comment 38. Rebooted and the context is correct.
Why is this BZ still in POST state?
I still have the following log during startup on a fedora 25 beta: Unable to fix SELinux security context of /dev/shm/lldpad.state: Permission denied
initscripts-9.65-2.fc24.x86_64 still contains /lib/systemd/fedora-import-state without the fix of comment #38 .
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Occured today in Rawhide
SELinux is preventing systemd-logind from getattr access on the file /dev/shm/sbis_shm_EventBroker_14382_READ_SEM. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-logind should be allowed getattr access on the sbis_shm_EventBroker_14382_READ_SEM file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd-logind' --raw | audit2allow -M my-systemdlogind # semodule -X 300 -i my-systemdlogind.pp Additional Information: Source Context system_u:system_r:systemd_logind_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects /dev/shm/sbis_shm_EventBroker_14382_READ_SEM [ file ] Source systemd-logind Source Path systemd-logind Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.2-16.fc29.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux localhost.localdomain 4.17.0-0.rc3.git4.1.fc29.x86_64 #1 SMP Fri May 4 19:41:58 UTC 2018 x86_64 x86_64 Alert Count 12 First Seen 2018-05-12 19:16:27 +05 Last Seen 2018-05-12 19:16:27 +05 Local ID c806993a-2e1a-491c-9e81-a040d905ebd4 Raw Audit Messages type=AVC msg=audit(1526134587.682:775): avc: denied { getattr } for pid=808 comm="systemd-logind" path="/dev/shm/sbis_shm_EventBroker_14382_READ_SEM" dev="tmpfs" ino=201280502 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0 Hash: systemd-logind,systemd_logind_t,tmpfs_t,file,getattr
> /dev/shm/sbis_shm_EventBroker This isn't “lldpad.state” file. You should report new bug against selinux-policy or the softwware creating this sbis_* file.
(In reply to Mikhail from comment #46) > SELinux is preventing systemd-logind from getattr access on the file > /dev/shm/sbis_shm_EventBroker_14382_READ_SEM. See comment 47.