From: Willy Tarreau <willy@w.ods.org>
To: Paul Jackson <pj@sgi.com>
Cc: solar@openwall.com, tigran@aivazian.fsnet.co.uk, alan@redhat.com,
marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org
Subject: Re: question about /proc/<PID>/mem in 2.4 (fwd)
Date: Mon, 19 Jul 2004 06:54:03 +0200 [thread overview]
Message-ID: <20040719045403.GA8212@alpha.home.local> (raw)
In-Reply-To: <20040718161549.5c61d4a9.pj@sgi.com>
On Sun, Jul 18, 2004 at 04:15:49PM -0700, Paul Jackson wrote:
> That original shell's mem file will be read by whatever follows, exec or
> not. The 'exec' just stops the shell from forking before it exec's, and
> certainly won't cause the path that was used earlier to open fd 0 to be
> re-evaluated.
I totally agree, of course, but...
> The setuidapp will see the shell's memory. In general, a app, setuid or
> not, should make no assumption that any open fd's handed to it at birth
> were opened using the same priviledges that the app itself has.
how can you be sure it will be the shell's memory ? after an exec, the
new process replaces the shell with the same pid. If it overwrites the
same address space, there's a possibility that /proc/self/mem, once
openned, still points to the same structure which will reflect the new
process's space after exec(). I'm afraid I'll have to test it.
Regards,
Willy
next prev parent reply other threads:[~2004-07-19 4:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-07 13:28 question about /proc/<PID>/mem in 2.4 (fwd) Tigran Aivazian
2004-07-07 23:48 ` Solar Designer
2004-07-18 12:41 ` Tigran Aivazian
2004-07-18 12:59 ` Solar Designer
2004-07-18 21:27 ` Willy Tarreau
2004-07-18 23:15 ` Paul Jackson
2004-07-19 4:54 ` Willy Tarreau [this message]
2004-07-19 6:47 ` Paul Jackson
2004-07-22 20:34 ` Alan Cox
2004-07-22 21:23 ` Paul Jackson
2004-07-23 17:34 ` Alan Cox
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=20040719045403.GA8212@alpha.home.local \
--to=willy@w.ods.org \
--cc=alan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=pj@sgi.com \
--cc=solar@openwall.com \
--cc=tigran@aivazian.fsnet.co.uk \
/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