Re: Cannot transition to radicale_t domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 06/30/2017 12:15 PM, Juan Orti Alcaine wrote:
2017-06-30 18:07 GMT+02:00 Bob Gustafson <bobgus@xxxxxxx>:


On 06/30/2017 10:19 AM, Stephen Smalley wrote:
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@xxxxxxxxxxxxxxxxxxxxxxg
To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
Check out

https://bugzilla.redhat.com/show_bug.cgi?id=1412696

There the PrivateDevices=true, in combination with selinux, caused postfix to quit unexpectedly.

​That is the answer, thank you very much.

Is it a bug?​


It probably is a bug, but since there is a workaround...

It has to do with the time sequence of applying selinux magic to several directories (/dev among them) after they are mounted. Something like that anyway.
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux