Project

General

Profile

Actions

Bug #1271

closed

Creating core dump with dropped privileges

Added by Andreas Herz over 9 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

I'm not sure if it's a bug or just a normal behaviour, but if i use another user for suricata (suri:suri for example) instead of root, i get

10/9/2014 -- 10:41:07 - <Info> - Core dump size is unlimited.
10/9/2014 -- 10:41:07 - <Info> - dropped the caps for main thread

So i guess with dropping the caps it looses the possibility to create a coredump. When i use root as user, it works.

Actions #1

Updated by Peter Manev over 9 years ago

Can you confirm that this is not related to permissions?
Example - the user "suricata" has no permissions to write in the coredump directory defined in suricata.yaml?

thanks

Actions #2

Updated by Andreas Herz over 9 years ago

Peter Manev wrote:

Can you confirm that this is not related to permissions?
Example - the user "suricata" has no permissions to write in the coredump directory defined in suricata.yaml?

How can i set the dir in the .yaml? couldn't find any documentation related to this.
I have the following in /etc/sysctl.conf and loaded it (for testing purpose):

kernel.core_pattern = /var/log/suricata/core_%e_%p_%s_%t

Since the folder is owned by suricata and it can write the logfiles (fast.log etc.) i doubt a permission issue.

Actions #3

Updated by Peter Manev over 9 years ago

# Daemon working directory

section in suricata.yaml
Actions #4

Updated by Andreas Herz over 9 years ago

Nothing defined, since it's not run in -D mode :)

Config is found here: http://paste.geekosphere.org/ZqatQTf8XLm6dRya (except that for the cap test the user part is changed from root to suricata and group as well)

Actions #5

Updated by Andreas Herz over 9 years ago

Not sure if it's directly related but i have the same issue with the pidfile.

suricata -c /etc/suricata/suricata-eth4.conf -q 0 --pidfile /tmp/suricata-eth4.pid

When i have user "root" in the .conf i get the pid file created and deleted after suricata quits.
When i have another user like "suricata" i get the pid file created but not deleted after suricata quits.

I start suricata as "root" user in the shell (or via script), so i let suricata drop the privileges.

Actions #6

Updated by Peter Manev over 9 years ago

What are the permissions of /tmp ?

Actions #7

Updated by Andreas Herz over 9 years ago

drwxrwxrwt   3 root root  27K Nov  6 09:12 tmp
Actions #8

Updated by Peter Manev over 9 years ago

Is that the case only when you use " -q 0 " ?

Actions #9

Updated by Andreas Herz over 9 years ago

Also with just "-i ethX" the pidfile is not deleted. In "-D" mode i can't say it for sure, since sending "kill -s TERM" is resulting in "Signal Received. Stopping engine." but doesn't stop suricata, it keeps running.

Actions #10

Updated by Peter Manev over 9 years ago

For testing coredump - can you try:

sudo kill -n ABRT `pidof suricata`

instead of kill -s TERM

On a separate note.
If there is no traffic coming on to the listening interface Suricata will not exit - as you describe. Can you confirm this is the case - when you stop Suricata there is no traffic on the interface?

thanks

Actions #11

Updated by Andreas Herz over 9 years ago

Using ABRT results in suricata being stopped but no coredump file and the pidfile not removed.
I tested it with and without traffic, behaviour didn't change.

If i start suricata without "-D" like this:

/usr/sbin/suricata -c /etc/suricata/suricata-eth4.conf -i eth4 --pidfile /tmp/suricata-test.pid

And after engine is started and i press CTRL+c i'm also stuck at the signal received/stopping engine part, even as root:root without dropping privileges.

Actions #12

Updated by Peter Manev over 9 years ago

I can confirm that actually (for 2.1beta2) - when running as a user - I can not get it to get a coredump.

Actions #13

Updated by Andreas Herz over 8 years ago

  • Assignee set to Andreas Herz
  • Target version set to TBD
Actions #14

Updated by Andreas Herz about 8 years ago

And still an issue with 3.0 as well btw

Actions #16

Updated by Andreas Herz almost 6 years ago

  • Assignee changed from Andreas Herz to Anonymous
Actions #17

Updated by Andreas Herz about 5 years ago

  • Assignee set to Community Ticket
Actions #18

Updated by Andreas Herz almost 5 years ago

There is some new discussion on this, see the linked PR

Actions #19

Updated by Victor Julien over 4 years ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Closed
  • Assignee changed from Community Ticket to Jason Ish
  • Priority changed from Low to Normal
  • Target version changed from TBD to 5.0rc1
Actions #20

Updated by Victor Julien over 4 years ago

  • Tracker changed from Feature to Bug
Actions

Also available in: Atom PDF