On Tue, 13.11.12 18:03, Thomas Woerner (twoerner@xxxxxxxxxx) wrote:
> The security team asked me not to make firewalld a D-BUS driven
> mechanism, because of security concerns and also because of SELinux.
Uh? If you write a new D-Bus service and want to use bus activation,
then you should SystemdService= in the dbus service snippet, so that the
actual activation is done by systemd. If you do that, then the effective
difference regarding the execution environment of the service is next to
zero, you just have two different triggers ("start this on boot"
vs. "start this when dbus tells systemd to").
In fact, all system bus services should be configured to defer
activation to systemd, so that all services regardless how they are
triggered are executed in the same clean execution environment, and can
be manipulated with the same commands (systemctl
stop/kill/restart/mask/...) as any other services.
In fact, even if you write a bus service that is started at boot, you
should *always* make it bus activatable as well. Why? For two reasons:
you make things robust that way, as the service is restarted when needed
should it have died, and you enable parallelized boot-up, since services
requiring your services don't have to be ordered explicitly after yours,
but can just talk to your service name and dbus will queue all messages
until your service is actually up.
Hence: please make your service bus-activatable. In all cases. There are
no security concerns, and you make things faster and more robust by
doing this.
> Additionally every load of the mechanism could have to load modified
> or removed configuration files. So how should it get to the same
> state then again? How should it react on and reflect configuration
> changes? So it would have to write out everything - the state and
> all configuration files. I am sorry, but this is overkill and a most
> likely a source of big problems.
Actually, no, it's not overkill, it's good coding practice. Most of
systemd's various little services (not all though) are written that they
can be killed and restarted at any time without losing any state (such
as logind, udevd, timedated, localed, hostnamed, ...). In fact even
systemd itself can exit and be reexecuted while recovering almost all
previous state. (In fact, currently the one exception of the systemd
services that can't just be killed without negative effect is journald,
but we are working on that).
It's really not that hard. I think it's a really good rule to make all
low-level system daemons work that way, to keep things robust and
resource usage minimal.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
