The user systemd service file could be installed in an other location than the
system ones. In debian for example, the system files are installed
/lib/systemd/system and the user ones in /usr/lib/systemd/user.
Suggested-by: Laurent Bigonville <bigon@bigon.be>
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Acked-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Make user restorecond systemd service consistent with restorecond_user.conf file
used by `restorecond -u`
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
When running restorecond in user sessions using D-Bus activation,
restorecond's process is spawned in the CGroup of the D-Bus daemon:
$ systemctl --user status
[...]
CGroup: /user.slice/user-1000.slice/user@1000.service
├─init.scope
│ ├─1206 /usr/lib/systemd/systemd --user
│ └─1208 (sd-pam)
└─dbus.service
├─1628 /usr/bin/dbus-daemon --session --address=systemd:
└─4570 /usr/sbin/restorecond -u
In order to separate it, introduce a systemd unit for
restorecond-started-as-user.
After this patch:
CGroup: /user.slice/user-1000.slice/user@1000.service
├─restorecond-user.service
│ └─2871 /usr/sbin/restorecond -u
├─init.scope
│ ├─481 /usr/lib/systemd/systemd --user
│ └─485 (sd-pam)
└─dbus.service
└─2868 /usr/bin/dbus-daemon --session --address=systemd:
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955940 states:
dbus-glib is a deprecated D-Bus library with some significant design
flaws, and is essentially unmaintained.
restorecond uses dbus-glib in order to spawn as a D-Bus service on the
session bus of users. This makes restorecond stays so long as the user
session exists.
Migrate from dbus-glib to GDbus API for the implementation of this
feature.
Moreover restorecond currently uses a D-Bus signal to trigger starting
the service. This is quite inappropriate, as stated for example in
https://dbus.freedesktop.org/doc/dbus-tutorial.html#members
Methods are operations that can be invoked on an object, with
optional input (aka arguments or "in parameters") and output (aka
return values or "out parameters"). Signals are broadcasts from the
object to any interested observers of the object; signals may
contain a data payload.
Implementing a method is more appropriate. It appears that all D-Bus
users can implement method Ping from interface org.freedesktop.DBus.Peer
(https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-peer)
and that calling this method is enough to trigger the launch of the
service. This can be tested in a shell by running:
gdbus call --session --dest=org.selinux.Restorecond \
--object-path=/ --method=org.freedesktop.DBus.Peer.Ping
As this method is automatically provided, there is no need to implement
its handling in the service.
Fixed: https://github.com/SELinuxProject/selinux/issues/217
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
For some reasons, restorecond was explicitly linking against libpcre but
the code is not using any of its symbols
Closes: https://github.com/SELinuxProject/selinux/issues/137
Signed-off-by: Laurent Bigonville <bigon@bigon.be>
There were several places in the makefiles where LDLIBS or CFLAGS were
supposed to include options to build. They were missing the override
keyword so would be skipped if these vars were set on the make cmdline.
Add the override directive to fix this.
Signed-off-by: Jason Zaman <jason@perfinion.com>
The toolchain automatically handles them and they break cross compiling.
LDFLAGS should also come before object files, some flags (eg,
-Wl,as-needed) can break things if they are in the wrong place)
Gentoo-Bug: https://bugs.gentoo.org/500674
Signed-off-by: Jason Zaman <jason@perfinion.com>
Now that restorecond is separated from policycoreutils, we should not
retain a build dependency on the policycoreutils/setfiles source files.
Fork the restore.[ch] files for restorecond.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Petr Lautrbach
Nicolas Iooss
Laurent Bigonville
Aleksei Nikiforov
Marcus Folkesson
Jason Zaman
Stephen Smalley