On 2017-01-02 01:47, David Sommerseth wrote:
> On 02/01/17 10:03, jdow wrote:
>>
>> I also found that I had no way I could find to tell systemd to bring up
>> a daemon as a relatively unprivileged user rather than root. Running
>> some services at root privileges makes me nervous even with SELinux in
>> place and active.
>
> $ man systemd.exec
>
>        User=, Group=
>            Sets the Unix user or group that the
>            processes are executed as,
>            respectively. Takes a single user or
>            group name or ID as argument. If no
>            group is set, the default group of the
>            user is chosen.

When I tried it I seemed to get unexpected results - subversion apparently 
insisted on remaining in the root privilege level. I may not have found the 
right place to put that into the xxx.service file. I found User=/Group= but the 
application of this remained obscure. I tried it under the [Service] heading. In 
retrospect does the order of placement under one of those headers make a difference?

> Which translates to providing User=/Group= in the [service] section of a
> unit file.

"Unit" is a bit of jargon that was not apparent at first. (hyperlinks work. It 
would be nice for people to use them more in HTML documentation first use in a 
section. {^_-})

> Other useful settings for hardening a service are Capabilities=,
> SecureBits=, PrivateTmp=, PrivateDevices=,  PrivateNetwork=,
> ProtectSystem=, ProtectHome=, RestrictAddressFamilies=,
> ReadWriteDirectories=, ReadOnlyDirectories= and InaccessibleDirectories=
> ... all documented in systemd.exec.
>
> And then there is Restart= which is fairly useful and to get a similar
> behaviour to daemontools, you can look into Type=simple (which is the
> default if not provided).  These are found in systemd.service.
>
> Getting a grip of the systemd man page hierarchy can be useful though.
> I generally find all the information I need when working on unit files
> for services in systemd.unit, systemd.service, systemd.exec and
> systemd.kill.  That usually covers most of the life cycle of a service.

Systemd has a steep and long learning curve, it appears. So a good GUI manager 
for it might be helpful, especially if it had some graphical features as well as 
text representations. The old init stuff was easier for somebody not making a 
career of the whole thing. If I was paid to sysadmin I'd dig in more than I can 
now. Other things are more fun for somebody not quite retired.

{^_-}