On 12/10/2015 11:42 AM, Simon McVittie wrote: > The approach I try to follow in dbus is that options that should be > changed by another package (such as default security policies) go in a > configuration file, or more recently a file in /usr/share; options that > should be changed by the sysadmin (such as security policies and > resource limits) also go in a configuration file; but system-integration > options (such as "use syslog" or "use systemd for activation") are > command-line options that can be forced to their > correct-for-this-distribution values by the ExecStart line in the > systemd unit, LSB init script or whatever. Unfortunately dbus doesn't > always follow this rule for historical reasons - <syslog/> is a > configuration-file option, but it shouldn't be. I like what the Genode folks are doing these days to solve this problem. It truly is brilliant and I wish Linux had anything like it:
When a program starts, its creator "container" creates a ROM dataspace
(a chunk of read-only memory that gets mapped into the memory space of
the program) and then passes the dataspace as a capability to the
program. The program then reads its configuration from the dataspace.
When the configuration file on disk is changed, the creator notices,
creates a brand new ROM dataspace, and pushes it to the program via
IPC. The program then has automatically mapped the new ROM dataspace
into its address space, but the new ROM dataspace is not active -- it is
up to the program to do whatever is necessary to make the new ROM
dataspace take effect, whenever it decides to do so.
All of this works without restarts, completely transparently and
automatically, and it's actual library code that is automatically reused
among ALL Genode programs, uses actual capability-based IPC, and is
entirely secure in a way no Linux program can be.
Meanwhile, we're still in 1980 dicking around with EnvironmentFiles and
FlagFiles and such bullshit.
But I do think that Genode has a vaiuable lesson here. If, say, systemd
gained the capability to "compile" configurations and push them to
daemons via memfd, and daemons learned how to catch those memfds and
reconfigure themselves as they are received -- a similar, but less
secure concept than what Genode does -- then we would have invented the
perfect reload pattern. Heck, systemd could even compile that stupid
EnvironmentFile and ship it to the daemon without having to do any sort
of evaluation on ExecStart... and perhaps even automatically ship the
compiled configuration as soon as its source is detected to have
changed, much like Genode does today.
Ah, a man can dream.
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
