Files
securityonion/salt/elasticfleet
Josh Patterson 1e86be11b2 FIX: install /usr/sbin management scripts as root
Salt installed the so-* scripts into /usr/sbin owned by unprivileged service
UIDs (939/socore, plus 930-960 per service) at mode 755, while root executes
those same files from cron, systemd and state cmd.run. Any file-write
primitive as one of those UIDs was therefore root.

Two mechanisms behind this are not visible in the diff:

file.recurse also manages the destination directory, so /usr/sbin itself was
chowned to whichever service UID ran last. A directory's owner may always
chmod it, so that UID could replace even the scripts already declared
user: root -- so-config-backup, so-suricata-eve-clean, so-nsm-mount-nvme.
usr_sbin_perms now pins the directory to root:root 555, the mode the
filesystem RPM ships.

Omitting user:/group: is a no-op on files that already exist, because
check_perms only chowns when a user is named. Explicit user: root is what
lets upgraded grids self-heal on the next highstate, and what makes a
revert chown back rather than silently do nothing.
2026-09-16 10:34:20 -04:00
..
2026-08-20 16:35:46 -05:00
2026-07-10 13:50:55 -05:00
2023-05-15 09:41:44 -04:00
2023-05-15 09:41:44 -04:00
2026-06-09 23:19:26 -05:00
2023-05-15 09:41:44 -04:00
2026-01-12 09:25:15 -05:00