mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bryan Donlan <bdonlan@gmail.com>
To: Timo Sirainen <tss@iki.fi>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Added PR_SET_PROCTITLE_AREA option for prctl()
Date: Fri, 2 Oct 2009 22:01:17 -0400	[thread overview]
Message-ID: <3e8340490910021901i35ba8a5v7647b1e02b054270@mail.gmail.com> (raw)
In-Reply-To: <1254518602.5050.4.camel@hurina>

On Fri, Oct 2, 2009 at 5:23 PM, Timo Sirainen <tss@iki.fi> wrote:
> PR_SET_PROCTITLE_AREA updates mm_struct->arg_start and arg_end to the
> given pointers, which makes it possible for user space to implement
> setproctitle(3) cleanly.


> @@ -267,9 +267,12 @@ static int proc_pid_cmdline(struct task_struct *task, char * buffer)
>
>        res = access_process_vm(task, mm->arg_start, buffer, len, 0);
>
> -       // If the nul at the end of args has been overwritten, then
> -       // assume application is using setproctitle(3).
> -       if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
> +       if (mm->arg_end != mm->env_start) {
> +               // PR_SET_PROCTITLE_AREA used
> +               res = strnlen(buffer, res);

Is this check really needed? Surely it's enough to simply state that
behavior if the area isn't null-terminated is undefined.

> +       } else if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
> +               // If the nul at the end of args has been overwritten, then
> +               // assume application is using old style setproctitle(3).
>                len = strnlen(buffer, res);
>                if (len < res) {
>                    res = len;

Might want to fix the bug later on in that function while you're in
here - the second access_process_vm call is never checked for errors,
but (from my reading) it's possible that the page that the environment
is on could be unmapped between those two calls. The result could
either be a short read (not the end of the world) or a negative value
(error code + small original argument length) passed to strnlen.

That said, come to think of it, I'm not actually sure if this prctl
stuff is strictly necessary. Wouldn't it be enough for glibc to copy
the environment somewhere safe, and then have the kernel guarantee a
full PAGE_SIZE between arg_start and env_end, even if this means
padding out the environment? The process could then measure to make
sure it has this much space (in case of running on an old kernel) by
testing the difference between arg_start and the top of the stack, or
an auxiliary vector could be passed down from the kernel with the
maximum proctitle length.

  reply	other threads:[~2009-10-03  2:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 21:23 Timo Sirainen
2009-10-03  2:01 ` Bryan Donlan [this message]
2009-10-03  2:47   ` Timo Sirainen
2009-10-03  2:59     ` Bryan Donlan
2009-10-03  3:21       ` Timo Sirainen
2009-10-04 14:44       ` KOSAKI Motohiro
2009-10-04 18:05         ` Bryan Donlan
2009-10-05  0:55           ` KOSAKI Motohiro
2009-10-05  1:38             ` KOSAKI Motohiro
2009-10-05  1:44               ` Bryan Donlan
2009-10-05  1:59                 ` KOSAKI Motohiro
2009-10-05  2:21                   ` Bryan Donlan
2009-10-05  2:24                     ` KOSAKI Motohiro
2009-10-05  2:48                       ` KOSAKI Motohiro
2009-10-05  3:22                         ` Bryan Donlan
2009-10-05  3:29                           ` KOSAKI Motohiro
2009-10-05  3:39                             ` Bryan Donlan
2009-10-05  7:18                               ` KOSAKI Motohiro
2009-10-05 22:56                         ` Timo Sirainen
2009-10-03 11:18 ` matthieu castet
2009-10-04 15:10   ` KOSAKI Motohiro

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=3e8340490910021901i35ba8a5v7647b1e02b054270@mail.gmail.com \
    --to=bdonlan@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tss@iki.fi \
    /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

all inboxes | Powered by JetHome®