public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Pereira Nunes <alex@PolesApart.wox.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Doubt: core not dumped when binary give up root privileges.
Date: Tue, 26 Aug 2003 13:52:37 -0300	[thread overview]
Message-ID: <3F4B9055.5070708@PolesApart.wox.org> (raw)
In-Reply-To: <1061913848.20910.55.camel@dhcp23.swansea.linux.org.uk>

Alan Cox wrote:

>On Gwe, 2003-08-22 at 20:25, Alexandre Pereira Nunes wrote:
>  
>
>>The program explicitly sets RLIMIT_CORE to RLIM_INFINITY when still 
>>running with uid 0.
>>    
>>
>
>The kernel assumes a core image from something that was priviledged may
>be unsafe.
>  
>
That makes sense... By that time, I took a look at the sources and found 
the prctl syscall, and with a little tweaking it was possible to do what 
I wish (keep reading)...

>  
>
>>If instead of calling the program as root, I call it from the non-priv 
>>uid in question, if it crashes, it dumps core on the mentioned dir. 
>>That's the desired behaviour, since I can then take the core and debug. 
>>But if I run it as root (in fact, I would have to), and it crashes (or 
>>is forced to ,by means of kill -SEGV), after it gives up root 
>>credentials, it won't leave a core dump file, which in turn means I 
>>cannot debug it later.
>>
>>Any ideas?
>>    
>>
>
>2.4-ac has support for enabling setuid core dumps and setting the dump
>path, so you can write such dumps to /root/dumps and the kernel will
>make them root accessible only.
>
>The 2.6 test tree and Marcelo 2.4 don't currently support this
>
>  
>

That's an interesting feature and is almost exactly what I needed: I 
wrote a daemon, which is started by root at boot time. In some point at 
startup, it chroot to an application-specific directory and gives up 
privileges. If it would dump core, it had to be on that directory, which 
has somewhat restrict permissions, so that I (and only I) can get it 
later for further analysis. By means of chroot + prctl it was possible 
to achieve this, but it would be simpler with this approach of yours, 
which could also help in debugging in case something else crashes. I'm 
inclined to adopting it, even though the daemon will ship to run on 
third-parties machines, and I'll have no much control of what kernel is 
running there (probably distribution default ones). I'll see what is 
possible here... Thank you!

Alexandre


      reply	other threads:[~2003-08-26 16:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-22 19:25 Doubt: core not dumped when binary give up root privileges Alexandre Pereira Nunes
2003-08-23  1:25 ` Alexandre Pereira Nunes
2003-08-26 16:04 ` Alan Cox
2003-08-26 16:52   ` Alexandre Pereira Nunes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F4B9055.5070708@PolesApart.wox.org \
    --to=alex@polesapart.wox.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox