Re: [PATCH v6] Added PR_SET_PROCTITLE_AREA option for prctl()

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

> 
> * Bryan Donlan <bdonlan@gmail.com> wrote:
> 
> > On Tue, Dec 8, 2009 at 12:38 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > >
> > >> > The feature looks useful, but the choice of a prctl as an API is strange
> > >> > - it limits us to the current task only - while the ability to set
> > >> > arguments for another task looks a more generic (and potentially more
> > >> > useful) solution.
> > >>
> > >> No. It's impossible.
> > >> /proc/{pid}/cmdline read user process's memory. iow, this prctl() don't
> > >> receive string, it receive virtual address itself. [...]
> > >
> > > it's not 'impossible' at all, you yourself mention ptrace:
> > 
> > If another process is going to use ptrace to inject the cmdline string 
> > into the victim's address space, it can also temporarily hijack a 
> > thread to run prctl() on its behalf...
> 
> That's exactly the point i made. There's no reason not to offer the API 
> i suggested as long as permissions are checked (as usual) - because 
> ptrace already allows this (and more).

Confused.

I think ptrace don't solve the issue of explained my patch description.
currently, proc title pointer is held by mm_struct (i.e. kernel), but string
isself is in userland.
then, if we want to use long proc tile, we need following three steps.
  1. make new userland space
  2. write proc title to it
  3. change proc title pointer in kernel

ptrace can only change exist userland memory. iow, it can only 
write same length string.
To expand another task's virtual address space makes lots trouble rather than
solving issue.

argv[0] and /proc/pid/cmdline are already special. generic api don't fit it, I think.