All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: "linux-os \(Dick Johnson\)" <linux-os@analogic.com>
Cc: "Andreas Schwab" <schwab@suse.de>,
	"Stefan Seyfried" <seife@suse.de>,
	linux-kernel@vger.kernel.org, christiand59@web.de
Subject: Re: /dev/stderr gets unlinked 8]
Date: Thu, 16 Mar 2006 10:07:51 +0200	[thread overview]
Message-ID: <200603161007.51237.vda@ilport.com.ua> (raw)
In-Reply-To: <Pine.LNX.4.61.0603150913540.12854@chaos.analogic.com>

On Wednesday 15 March 2006 16:23, linux-os (Dick Johnson) wrote:
> 
> On Wed, 15 Mar 2006, Denis Vlasenko wrote:
> 
> > On Wednesday 15 March 2006 15:14, Andreas Schwab wrote:
> >> Stefan Seyfried <seife@suse.de> writes:
> >>
> >>> any good daemon closes stdout, stderr, stdin
> >>
> >> A real good daemon would redirect them to /dev/null.
> >
> > Yeah, yeah, let's first close stderr, and then proceed and
> > add some code to handle command line --log=file, and to do
> > logging to that file.
> >
> > Why good ol' fprintf(stderr,...) isn't enough? Why do you
> > want to complicate things?
> >
> > What's so hard in doing "daemon 2>/dev/null &" if you don't
> > want to save log?
> > --
> > vda
> 
> The daemon needs to have the standard input closed as well as
> any I/O connection to a possible terminal. Just closing
> standard input, allows a dup() in rogue code to recreate it.
> Basically, file-descriptors 0, 1, and 2, need to be USED and
> used for something else (like open /dev/null or open "/").
> That's how you prevent rogue code, inserted via overflow or
> other means, from obtaining control of your system.

... and everything described above is perfectly doable by
shell mechanisms (like redirections) prior to strting daemon, right?
--
vda

  reply	other threads:[~2006-03-16  8:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-14 10:12 /dev/stderr gets unlinked 8] Denis Vlasenko
2006-03-14 13:07 ` Aurelien Degremont
2006-03-14 13:11   ` Denis Vlasenko
2006-03-14 13:11 ` Christian
2006-03-14 13:35   ` Denis Vlasenko
2006-03-15 11:02     ` Stefan Seyfried
2006-03-15 13:14       ` Andreas Schwab
2006-03-15 13:34         ` Denis Vlasenko
2006-03-15 14:23           ` linux-os (Dick Johnson)
2006-03-16  8:07             ` Denis Vlasenko [this message]
2006-03-16 20:11         ` Jan Engelhardt
2006-03-17  6:34           ` Denis Vlasenko
2006-03-17 14:32             ` Jan Engelhardt
2006-03-17 15:40               ` linux-os (Dick Johnson)
2006-03-15 13:30       ` Denis Vlasenko
     [not found] <5QeND-31x-7@gated-at.bofh.it>
     [not found] ` <5QE55-6Td-9@gated-at.bofh.it>
     [not found]   ` <5R778-8fs-29@gated-at.bofh.it>
     [not found]     ` <5RgN2-5fi-3@gated-at.bofh.it>
     [not found]       ` <5RohF-7Oe-3@gated-at.bofh.it>
     [not found]         ` <5Rpnz-ZJ-39@gated-at.bofh.it>
2006-03-19  1:07           ` Bodo Eggert
2006-03-19 16:57             ` Joshua Hudson

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=200603161007.51237.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=christiand59@web.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=schwab@suse.de \
    --cc=seife@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.