On Fri, 2017-06-30 at 11:07 -0400, Stephen Smalley wrote: > On Fri, 2017-06-30 at 16:39 +0200, Juan Orti Alcaine wrote: > > > > 2017-06-30 16:39 GMT+02:00 Stephen Smalley <sds@xxxxxxxxxxxxx>: > > > On Fri, 2017-06-30 at 16:23 +0200, Juan Orti Alcaine wrote: > > > > 2017-06-30 14:23 GMT+02:00 Juan Orti Alcaine <j.orti.alcaine@gm > > > > ai > > > > > > l.co > > > > m>: > > > > > 2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec@xxxxxxxxxx>: > > > > > > On 06/28/2017 09:36 AM, Thomas Mueller wrote: > > > > > > > Hey Juan > > > > > > > > > > > > > > > I'm troubleshooting the radicale policy but I cannot > > > > > > figure > > > > > > > > why the service fails to transition to radicale_t. It > > > > > > runs in > > > > > > > > the init_t domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How you starting this service? > > > > > > > > > > > > > > > > systemctl start radicale.service > > > > > > > > > > > > > > > > > > I cannot find where is the problem, I see other daemons are > > > > also > > > > using init_daemon_domain. Why mine is it not transitioning? > > > > > > What's in your unit file? Certain systemd options can prevent > > > SELinux > > > transitions or disable SELinux functionality (e.g. > > > NoNewPrivileges, > > > ProtectKernelTunables). > > > > # /usr/lib/systemd/system/radicale.service > > [Unit] > > Description=Radicale CalDAV and CardDAV server > > Documentation=http://radicale.org/documentation/ > > After=network-online.target > > Requires=network-online.target > > > > [Service] > > WorkingDirectory=/var/lib/radicale > > User=radicale > > Group=radicale > > UMask=0027 > > Type=forking > > PIDFile=/var/run/radicale/radicale.pid > > ExecStart=/usr/bin/radicale --daemon -- > > pid=/var/run/radicale/radicale.pid > > PrivateTmp=true > > PrivateDevices=true > > CapabilityBoundingSet= > > ProtectSystem=full > > ProtectHome=true > > Restart=always > > > > [Install] > > WantedBy=multi-user.target > > systemd version? > > I'm guessing that one of the above options is automatically enabling > NoNewPrivileges=yes and needs to be disabled. Note to Fedora SELinux > maintainers: something needs to be done about systemd and its > handling > of NoNewPrivileges and ProtectKernelTunables, or we can only expect > more instances of such breakage... Looks like it is PrivateDevices=true. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx