Project

General

Profile

Actions
Copy link

Bug #2424

closed
RS CT

suri->userid (SCInstance) does not reflect correct uid if suricata is started as non-root

Bug #2424: suri->userid (SCInstance) does not reflect correct uid if suricata is started as non-root

Added by Richard Sailer over 8 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Low
Assignee:
Community Ticket
Target version:
TBD
Affected Versions:
Effort:
Difficulty:
Label:

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?

RS Updated by Richard Sailer over 8 years ago Actions
Copy link
 #1

  • Description updated (diff)

RS Updated by Richard Sailer over 8 years ago Actions
Copy link
 #2

  • Description updated (diff)

RS Updated by Richard Sailer over 8 years ago Actions
Copy link
 #3

  • 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

RS Updated by Richard Sailer over 8 years ago Actions
Copy link
 #4

  • Description updated (diff)

AH Updated by Andreas Herz over 8 years ago Actions
Copy link
 #5

  • Target version set to TBD

AH Updated by Andreas Herz about 7 years ago Actions
Copy link
 #6

  • Assignee changed from Richard Sailer to Anonymous

AH Updated by Andreas Herz about 7 years ago Actions
Copy link
 #7

  • Assignee set to Community Ticket

PA Updated by Philippe Antoine 10 months ago Actions
Copy link
 #8

Not sure there is a use case with a problem indeed...

JI Updated by Jason Ish 9 months ago Actions
Copy link
 #9

  • Status changed from Feedback to Closed

I'm going to close this issue.

Privilege dropping doesn't work if started as non-root, so we'd never get to point a runtime where setting the gid/uid would ever make sense. I also don't think we care about the possibility of being part of multiple groups, we only care about the one we want the files to be created with.

In short, I think we work as designed here, and within the scope of a UNIX system.

Actions
Copy link

Also available in: PDF Atom