On 02/10/2014 02:52 PM, David Sommerseth wrote:
> On 10/02/14 23:02, Tom H wrote:
>> To see a "complex" systemd service file, take a look at a Fedora 20
>> nfs-utils; nfsd is started by three lines:
>>
>> ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig
>> ExecStartPre=/usr/sbin/exportfs -r
>> ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT
>>
>> I would've used just one ExecStart calling
>> "/usr/lib/nfs-utils/scripts/nfs-server.script" but the maintainer
>> clearly disagrees. :)
> Yeah, and I can actually understand a little bit why.  Because systemd
> can track the services it has started quite carefully, even after they
> have been started.  And can take actions if they die.  By starting those
> three from a single script, it would only be able to track that script
> and not all those "features" the script starts.
>
> Another thing is that logging can be somewhat simpler too, and you are
> always guaranteed that logging goes via systemd, even things which goes
> to stdout (and stderr? I don't recall now).  A script can easily do odd
> tweaks there too.
>
> So by doing as much as possible in the systemd unit file, it gets less
> convoluted and a bit easier to follow what should happen if you need to
> debug.
>
>
> --
> kind regards,
>
> David Sommerseth
Does this not make systemd a prime target for attack and compromise?  
How hardened is systemd?

Yasha Karant