On Thu, May 23, 2013 at 07:16:18AM +0200, Zbigniew J??drzejewski-Szmek wrote: > Providing a conversion script which recreates all of systemd > functionality would basically mean reimplemting a big part of > systemd in shell. Providing an interpeter would man reimplementing > a big part of systemd in whatever the interpreter is written in. > Both options seem infeasible, unless only partial functionality is > supported. [1] lists e.g. SystemCallFilter=, PrivateTmp=, PrivateNetwork=, > CapabilityBoundingSet=, SecuritBits= which have security and > correctness implications, and are IMHO pretty hard to recreate.
I partly disagree here. A good reason to reimplement part of systemd is to have a portable subset of its functionality. This could be part of the answer to the question of what to do about kfreebsd. All the examples you give are Linux-specific, but at least SystemCallFilter[1] and CapabilityBoundingSet[2] are not that hard to reimplement, if you can change the process invoking the daemon (what start-stop-daemon is being now). But those examples are also the ones that I consider non-essential, because they are more of a hardening aspect. Also note that upstart has shown a similar integration to work and we shipped it in wheezy. It is called /lib/init/upstart-job. You can link that binary to /etc/init.d/$service to tell insserv that this service is provided by an upstart job. Instead of reading LSB headers from the wrapper, insserv will execute it with a lsb-headers parameter and read the output. The other runtime component is startpar-upstart-inject, which tells startpar about the completion of a job. As can be seen the upstart people have already done the heavy lifting here. Helmut [1] http://outflux.net/teach-seccomp/ [2] libcap-dev or libcap-ng-dev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130523071410.ga16...@alf.mars
