Description of problem: Starting vnc service causes SELinux alert, SELinux is preventing systemd from 'read' accesses on the file eagle.home.com:91.pid. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd should be allowed read access on the eagle.home.com:91.pid 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' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:user_home_t:s0 Target Objects eagle.home.com:91.pid [ file ] Source systemd Source Path systemd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-224.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.8.10-300.fc25.x86_64 #1 SMP Mon Nov 21 18:59:16 UTC 2016 x86_64 x86_64 Alert Count 6 First Seen 2016-12-05 10:16:56 GMT Last Seen 2016-12-05 10:24:02 GMT Local ID b761e55e-aca3-4bb8-8707-a206945f688d Raw Audit Messages type=AVC msg=audit(1480933442.565:505): avc: denied { read } for pid=1 comm="systemd" name="eagle.home.com:91.pid" dev="dm-11" ino=33575022 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=0 Hash: systemd,init_t,user_home_t,file,read Version-Release number of selected component: selinux-policy-3.13.1-224.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.10-300.fc25.x86_64 type: libreport Potential duplicate: bug 1366812
Steps to Reproduce: useradd fred cp -vp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:91.service sed -i 's/<USER>/fred/g' /etc/systemd/system/vncserver@:91.service systemctl daemon-reload systemctl enable vncserver@:91.service
Issue is caused by this line in vncserver.service line: PIDFile=/home/<USER>/.vnc/%H%i.pid Any chance to have it in /run directory?
/run/ is owned by root, so no chance of that. /run/user/<UID>/ only gets created during an X logged, so can't use that. I don't think /run can be used? Thanks
Hi, any update on this? Thanks
Description of problem: While VNC server was running, once interupted (Ctrl + Z). Version-Release number of selected component: selinux-policy-3.13.1-225.11.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.9.14-200.fc25.x86_64 type: libreport
Description of problem: "System Administrator Guide" for Fedora 25 Chaper 9 (TigerVNC) SELInux appears to block access to the user's pid file on step 9.1.3 (attempting to start the vncserver service). "journalctl -xe" shows the error "setroubleshoot[...]: SELinux is preventing systemd from unlink access on the file username:2.pid. For complete SELinux messages. run sealert -l [...]" Version-Release number of selected component: selinux-policy-3.13.1-225.11.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.10.8-200.fc25.x86_64 type: libreport
Description of problem: It happens when the system starts. I only notice it because of the SELinux message and in this case I think is related with problems with the gnome volume control Since this SELinux reports started showing up I have a problem with the sound bolume control. The control of the volume with the keyboard is not working, as the gnome volume control. I Have to go to the gnome settings to get control of the volume. Version-Release number of selected component: selinux-policy-3.13.1-225.13.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.10.11-200.fc25.x86_64 type: libreport
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.
Same issue with rawhide F28 Many thanks.
See also bug 1412468 which describes exactly the same problem. It's also a problem in Fedora 26 (and I'd guess Fedora 27).
The problem is actually a very straightforward change to the vncserver@.service copy in /etc/systemd/system: Instead of =========================== [Service] Type=forking # Clean any existing files in /tmp/.X11-unix environment ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :' ExecStart=/usr/sbin/runuser -l <USER> -c "/usr/bin/vncserver %i" PIDFile=/home/<USER>/.vnc/%H%i.pid ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :' =========================== Use ========================== [Service] Type=forking User=<USER> # Clean any existing files in /tmp/.X11-unix environment ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :' ExecStart=/usr/bin/vncserver %i PIDFile=/home/<USER>/.vnc/%H%i.pid ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :' ========================== Gnome isn't starting properly, but that's a different problem.
(There's an selinux problem preventing gnome starting up, not got to the bottom of that yet.)
It's an selinux problem writing to the PID file. Remove that line as well and all is fine. I also added Environment=XDG_SESSION_TYPE=x11 to the [Service] section otherwise vnc just sits there with a black screen.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
*** Bug 1549257 has been marked as a duplicate of this bug. ***
Confirming also a problem with Fedora 27 Server. Same set of errors in the journal, as with others: SELinux is preventing systemd from open access on the file /home/username/.vnc/hosname:1.pid. I followed the instructions on the wiki: https://docs.fedoraproject.org/f27/system-administrators-guide/infrastructure-services/TigerVNC.html # sudo systemctl start vncserver@:1.service Errors here # sudo systemctl stop vncserver@:1.service # ps -ef | grep vnc # kill 935 # sudo ausearch -c 'systemd' --raw | audit2allow -M my-systemd # sudo semodule -X 300 -i my-systemd.pp # sudo systemctl start vncserver@:1.service Still failed here for some reason # sudo systemctl stop vncserver@:1.service # ps -ef | grep vnc # kill 12695 # rm -R ./.vnc # vncpasswd # sudo systemctl start vncserver@:1.service Failed again # sudo ausearch -c 'systemd' --raw | audit2allow -M my-systemd # sudo semodule -X 300 -i my-systemd.pp # ps -ef | grep vnc # sudo systemctl stop vncserver@:1.service # ps -ef | grep vnc # kill 13963 # sudo systemctl start vncserver@:1.service NOW it works. Don't know what happened there the first time. my-systemd.te ------------- module my-systemd 1.0; require { type init_t; type user_home_t; class file { open read unlink }; } #============= init_t ============== allow init_t user_home_t:file open; #!!!! This avc is allowed in the current policy allow init_t user_home_t:file { read unlink };
*** This bug has been marked as a duplicate of bug 1418463 ***
Same issue with F31.