Bug #2424
opensuri->userid (SCInstance) does not reflect correct uid if suricata is started as non-root
Description
This currently happens if e.g. suricata is started as non root and does not drop privileges.
This is because suri->userid and suri->groupid are initialised to 0 and only changed once:
In InitSignalHandler() when suricata knows it will drop privileges, they are changed to the new uid/gid suricata will drop privs to.
I'm not sure how problematic this is, so I'm asking if this is worth fixing. Currently suri->userid is only used for changing privs and never again, so this bug does not really break anything, but it could if someone would rely on suri->userid for something else.
Also if I would fix it, what would be a nice place, to call getuid() and getgid(). SCInstanceInit() ?
And another thought: Usually unix process do not have a single gid, but one primary gid and several supplementary gids (https://en.wikipedia.org/wiki/Group_identifier#Supplementary_groups). Should SCInstance reflect that too?
Updated by Richard Sailer almost 7 years ago
- Subject changed from suri->userid (SCInstance) does not reflect correct uid, if suricata is started as non-root to suri->userid (SCInstance) does not reflect correct uid if suricata is started as non-root
Updated by Andreas Herz over 5 years ago
- Assignee changed from Richard Sailer to Anonymous