Project

General

Profile

Actions
Copy link

Bug #1271

closed
AH JI

Creating core dump with dropped privileges

Bug #1271: Creating core dump with dropped privileges

Added by Andreas Herz over 11 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Jason Ish
Target version:
5.0rc1
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.

PM Updated by Peter Manev over 11 years ago Actions
Copy link
 #1

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

AH Updated by Andreas Herz over 11 years ago Actions
Copy link
 #2

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.

PM Updated by Peter Manev over 11 years ago Actions
Copy link
 #3 

# Daemon working directory

section in suricata.yaml

AH Updated by Andreas Herz over 11 years ago Actions
Copy link
 #4

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)

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

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.

PM Updated by Peter Manev over 11 years ago Actions
Copy link
 #6

What are the permissions of /tmp ?

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

drwxrwxrwt   3 root root  27K Nov  6 09:12 tmp

PM Updated by Peter Manev over 11 years ago Actions
Copy link
 #8

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

AH Updated by Andreas Herz over 11 years ago Actions
Copy link
 #9

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.

PM Updated by Peter Manev over 11 years ago Actions
Copy link
 #10

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

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

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.

PM Updated by Peter Manev over 11 years ago Actions
Copy link
 #12

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

AH Updated by Andreas Herz over 10 years ago Actions
Copy link
 #13

  • Assignee set to Andreas Herz
  • Target version set to TBD

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

And still an issue with 3.0 as well btw

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

  • Assignee changed from Andreas Herz to Anonymous

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

  • Assignee set to Community Ticket

AH Updated by Andreas Herz over 6 years ago Actions
Copy link
 #18

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

VJ Updated by Victor Julien over 6 years ago Actions
Copy link
 #19

  • 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

VJ Updated by Victor Julien over 6 years ago Actions
Copy link
 #20

  • Tracker changed from Feature to Bug
Actions
Copy link

Also available in: PDF Atom