Bug 228519 - sysutils/beats daemons should probably not run as root
Summary: sysutils/beats daemons should probably not run as root
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-elastic (Nobody)
URL:
Keywords:
: 217081 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-05-26 20:34 UTC by Palle Girgensohn
Modified: 2020-12-29 18:11 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (elastic)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Palle Girgensohn freebsd_committer 2018-05-26 20:34:18 UTC 
the *beats daemons should probably not run as root

Running as nobody is not correct since the daemons own files in /var/db/beats/*beat. Hence the correct way is probably to create a `beats' user and ditto group. That way, admins can allow the beats group read access to log files that are not world readable, for example. 

Thoughs on this?

Palle
Comment 1 Palle Girgensohn freebsd_committer 2018-05-26 20:35:33 UTC 
*** Bug 217081 has been marked as a duplicate of this bug. ***
Comment 2 Mark Felder freebsd_committer 2018-06-13 19:11:03 UTC 
I had a similar thought, but that means you need to put beats user into groups that own various log files, etc. I think on Linux everyone runs it as root, but I need to do some more research. That's not a great excuse for running it as root, but if I am correct it would mean we diverge from other platforms.

At least beats doesn't open a listening socket on the network...
Comment 3 Juraj Lutter freebsd_committer 2020-12-29 16:48:14 UTC 
(In reply to Mark Felder from comment #2)
I can second that. beats needs various open files that might not be accessible from non-root user. Like logs, /proc entries, and such.
Comment 4 Dmitry Sivachenko freebsd_committer 2020-12-29 18:11:41 UTC 
I does not *always* need special privileges. There are a number of cases when it sends world-readable logs. Add an ability to change user (probably with root as default) would be handy.