Bug 1284293 - SELinux is preventing systemd-logind from getattr access on the file /dev/shm/lldpad.state [NEEDINFO]
SELinux is preventing systemd-logind from getattr access on the file /dev/shm...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
RejectedBlocker
: Reopened
: 1286167 1297142 1300825 1317299 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-22 18:30 EST by Dominic Robinson
Modified: 2018-05-14 07:27 EDT (History)
43 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-05-14 07:27:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
awilliam: needinfo? (lnykryn)
lvrabec: needinfo? (systemd-maint)


Attachments (Terms of Use)

  None (edit)
Description Dominic Robinson 2015-11-22 18:30:48 EST
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.
Comment 1 Lukas Vrabec 2015-11-23 05:15:49 EST
Hi, 
Could you attach outputs of:
# ls -Z /dev/shm/lldpad.state 
# sealert -l a7110687-2ca5-49cc-8d57-4fec455834a3

Thank you!
Comment 2 Dominic Robinson 2015-11-23 08:02:31 EST
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.
Comment 3 Dominic Robinson 2015-11-23 10:42:40 EST
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.
Comment 4 Dominic Robinson 2015-12-15 16:15:18 EST
This is still an issue if anyone cares.
Comment 5 JM 2015-12-16 07:07:47 EST
Same problem with Fedora 22.
Comment 6 Miroslav Grepl 2015-12-20 06:05:25 EST
*** Bug 1286167 has been marked as a duplicate of this bug. ***
Comment 8 Norman Smith 2015-12-24 13:50:39 EST
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.
Comment 9 Norman Smith 2015-12-24 18:17:10 EST
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.
Comment 10 Norman Smith 2015-12-25 17:47:34 EST
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.
Comment 11 Dominic Robinson 2015-12-26 07:56:12 EST
(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
Comment 12 Norman Smith 2015-12-26 16:02:06 EST
(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.
Comment 13 Dominic Robinson 2015-12-26 17:39:41 EST
(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!
Comment 14 Lukas Vrabec 2016-01-12 10:30:06 EST
*** Bug 1297142 has been marked as a duplicate of this bug. ***
Comment 15 Lukas Vrabec 2016-02-09 04:53:57 EST
*** Bug 1300825 has been marked as a duplicate of this bug. ***
Comment 16 Giulio 'juliuxpigface' 2016-02-25 16:42:49 EST
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
Comment 17 Lukas Vrabec 2016-03-15 12:46:34 EDT
*** Bug 1317299 has been marked as a duplicate of this bug. ***
Comment 18 Lukas Vrabec 2016-03-16 11:37:06 EDT
Hi lldpad folks,
Is it possible to run "/usr/sbin/restorecon /dev/shm/lldpad.state" in "ExecStart" in lldpad service file? 


Thank you!
Comment 19 Dominic Robinson 2016-03-24 17:10:33 EDT
@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.
Comment 20 Chris Leech 2016-03-24 17:28:44 EDT
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
Comment 21 Lukas Vrabec 2016-03-29 06:58:04 EDT
Great, 
Thank you, Chris for help. 

Is it possible to add cleanup dracut hooks also to Fedora? 

Thank you.
Comment 22 Harald Hoyer 2016-04-14 08:02:37 EDT
(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.
Comment 23 Harald Hoyer 2016-04-14 08:30:54 EDT
(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.
Comment 24 Harald Hoyer 2016-04-14 08:42:32 EDT
(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
Comment 25 Chris Murphy 2016-05-29 18:12:18 EDT
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
Comment 26 Kamil Páral 2016-05-31 09:57:05 EDT
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
Comment 27 Filipe Rosset 2016-05-31 20:51:31 EDT
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
Comment 28 Fedora Blocker Bugs Application 2016-05-31 21:39:15 EDT
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.
Comment 29 Zdenek Chmelar 2016-06-01 13:10:49 EDT
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
Comment 30 Adam Williamson 2016-06-02 20:11:21 EDT
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?
Comment 31 Kamil Páral 2016-06-03 04:13:31 EDT
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).
Comment 32 Chris Murphy 2016-06-03 20:20:16 EDT
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.
Comment 33 erzent 2016-06-04 11:39:55 EDT
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.
Comment 34 Geoffrey Marr 2016-06-04 23:25:23 EDT
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
Comment 35 Geoffrey Marr 2016-06-06 15:19:13 EDT
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
Comment 36 erzent 2016-06-07 09:02:07 EDT
 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
Comment 37 srakitnican 2016-07-25 08:58:39 EDT
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
Comment 38 Adam Williamson 2016-08-19 14:31:43 EDT
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?
Comment 39 Norman Smith 2016-09-28 09:08:28 EDT
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.
Comment 40 Lukas Vrabec 2016-10-03 06:58:56 EDT
Why is this BZ still in POST state?
Comment 41 fred 2016-10-10 05:22:10 EDT
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
Comment 42 Edgar Hoch 2016-10-23 15:48:06 EDT
initscripts-9.65-2.fc24.x86_64 still contains /lib/systemd/fedora-import-state without the fix of comment #38 .
Comment 43 Fedora End Of Life 2016-11-24 08:38:48 EST
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.
Comment 44 Fedora End Of Life 2016-12-20 11:10:50 EST
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.
Comment 45 Mikhail 2018-05-12 11:19:32 EDT
Occured today in Rawhide
Comment 46 Mikhail 2018-05-12 11:22:10 EDT
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
Comment 47 Tomasz Torcz 2018-05-12 11:28:41 EDT
> /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.
Comment 48 Jan Synacek 2018-05-14 07:27:33 EDT
(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.

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