All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chase Venters <chase.venters@clientec.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Greg KH <gregkh@suse.de>, "Scott J. Harmon" <harmon@ksu.edu>,
	linux-kernel@vger.kernel.org, stable@kernel.org,
	torvalds@osdl.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Linux 2.6.17.4
Date: Thu, 6 Jul 2006 18:57:25 -0500	[thread overview]
Message-ID: <200607061857.49153.chase.venters@clientec.com> (raw)
In-Reply-To: <20060706234918.GB2037@1wt.eu>

On Thursday 06 July 2006 18:48, Willy Tarreau wrote:
> Interestingly, 2.4 tests (arg2 !=0 && arg2 != 1) so from the code changes
> above, it looks like the value 2 was added on purpose, but for what ? Maybe
> the fix is not really correct yet ?

Hence the source of my curiosity. My prctl() manpage says that 2 makes a core 
that is only readable by root.

       PR_SET_DUMPABLE
              (Since  Linux 2.4) Set the state of the flag determining whether
              core dumps are produced for this process upon delivery of a sig-
              nal  whose  default  behaviour is to produce a core dump.  (Nor-
              mally this flag is set for a  process  by  default,  but  it  is
              cleared  when  a set-user-ID or set-group-ID program is executed
              and also by various system calls that  manipulate  process  UIDs
              and  GIDs).  In kernels up to and including 2.6.12, arg2 must be
              either 0 (process is not dumpable) or 1 (process  is  dumpable).
              Since  kernel 2.6.13, the value 2 is also permitted; this causes
              any binary which normally would not be dumped to be dumped read-
              able   by   root   only.    (See   also   the   description   of
              /proc/sys/fs/suid_dumpable in proc(5).)

> Cheers,
> Willy

Thanks,
Chase

  parent reply	other threads:[~2006-07-06 23:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-06 22:27 Linux 2.6.17.4 Greg KH
2006-07-06 22:28 ` Greg KH
2006-07-06 22:43   ` Scott J. Harmon
2006-07-06 22:46     ` Greg KH
2006-07-06 22:54       ` Scott J. Harmon
2006-07-07  6:12         ` Jan Engelhardt
2006-07-06 23:49       ` Willy Tarreau
2006-07-06 23:53         ` [stable] " Greg KH
2006-07-06 23:56         ` Chris Wright
2006-07-06 23:57         ` Chase Venters [this message]
2006-07-06 23:24   ` Chase Venters
2006-07-06 23:54     ` [stable] " Greg KH
2006-07-07 10:34     ` Marcel Holtmann

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=200607061857.49153.chase.venters@clientec.com \
    --to=chase.venters@clientec.com \
    --cc=akpm@osdl.org \
    --cc=gregkh@suse.de \
    --cc=harmon@ksu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@osdl.org \
    --cc=w@1wt.eu \
    /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.