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.

{^_-}

Reply via email to