Running exporter as non-root? sudo for calls to smartctl?

[frittentheke]

I was wondering if it was really necessary to run the whole smartctl_exporter as root. This is even promoted via the provided systemd unit https://github.com/prometheus-community/smartctl_exporter/blob/master/systemd/smartctl_exporter.service

I know smartctl does seem to require this (https://github.com/smartmontools/smartmontools/issues/205). But maybe there is a way to not require for the exporter to run as root but to just call a privileged smartctl? Is the good old sudo the right approach? Just by setting smartctl.path to sudo smartctl.path maybe?

[lahwaacz]

You can easily switch various security features of the systemd service to see what works and what not. I don't see an advantage in adding another layer with sudo...

[NiceGuyIT]

Adding sudo to the exporter is not going to happen.

As suggested by @lahwaacz, if you figure out how to configure systemd to improve the security, PRs are welcome!

[k0ste]

@frittentheke FYI prometheus-smartctl-exporter.service in AUR If you can test it, tune it, PR it - it can be part of smartctl_exporter tarball

[frittentheke]

I see my provocation of creativity by just mentioning sudo worked :-). Thanks for taking the quest to reduce the privileges seriously and let's see if there is something that could work for most installs.

[DaAwesomeP]

The AUR service unit looks very promising! Unfortunately I am not able to test/pull at this time.

The full documentation of these options can he found here: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Note that not all distros ship the latest Systemd, so newer options may result in warnings in the journal. However, in my experience it is backward-compatible without issue (you may not get all of the security features but still as many as possible).

[subnix]

I'm looking for a secure way to run the exporter too. These privileges are required for smartctl:

1. CAP_SYS_RAWIO capability to be able to access raw devices;
2. disk user group, which owns all the disks.

So you can add these lines to the systemd unit:

[Service]
...
CapabilityBoundingSet=CAP_SYS_RAWIO
AmbientCapabilities=CAP_SYS_RAWIO
Group=disk
...

But this set of privileges may lead to privilege escalation since root filesystem is accessible for writing. So sudo with limiting sudoers configuration still looks more secure.