Added PR_SET_PROCTITLE_AREA option for prctl()
in [Kernel]
|
Prev: pciehp_driver.c: PCIe hot plug for Intel iommu - call IOMMU API in hot remove
Next: 2.6.31 regression sis5513 PIO Mode 0 hang
From: Ingo Molnar on 8 Dec 2009 02:00 * Bryan Donlan <bdonlan(a)gmail.com> wrote: > On Tue, Dec 8, 2009 at 12:38 AM, Ingo Molnar <mingo(a)elte.hu> wrote: > > > > * KOSAKI Motohiro <kosaki.motohiro(a)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). Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 8 Dec 2009 02:00 * KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: > > > > > > * KOSAKI Motohiro <kosaki.motohiro(a)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: > > > > Ah yes, 'impossible' was wrong word. but it doesn't works intentionally. > > > > 1. setproctitle() unaware application continue to see argv[0] directly. > > it makes some inconsistent behavior. > > 2. proc title (i.e. string) injection need to map new page as process title area. > > implicit mapping increasing makes new trouble > > - mihgt cause to exceed max_map_count awhile after. > > - might cause leak proc title area (who know when it should be freed?) > > > > I think reasonable way is 1. send signal (or use another inter process > > communication way) to target process 2. target process change own proc title > > themself. > > > > Plus, I haven't seen the use-case of changin another task. iow I doubt > > it's worth to change lots code. > > if your mention is strongly, can you please explain your expected use > case? I have no strong opinion - i just raised the possibility. We try to avoid special-purpose APIs for new syscalls - we try to design them in a generic way. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 8 Dec 2009 02:00 > > > > * KOSAKI Motohiro <kosaki.motohiro(a)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: > > Ah yes, 'impossible' was wrong word. but it doesn't works intentionally. > > 1. setproctitle() unaware application continue to see argv[0] directly. > it makes some inconsistent behavior. > 2. proc title (i.e. string) injection need to map new page as process title area. > implicit mapping increasing makes new trouble > - mihgt cause to exceed max_map_count awhile after. > - might cause leak proc title area (who know when it should be freed?) > > I think reasonable way is 1. send signal (or use another inter process > communication way) to target process 2. target process change own proc title > themself. > > Plus, I haven't seen the use-case of changin another task. iow I doubt > it's worth to change lots code. if your mention is strongly, can you please explain your expected use case? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 8 Dec 2009 02:20 > > * Bryan Donlan <bdonlan(a)gmail.com> wrote: > > > On Tue, Dec 8, 2009 at 12:38 AM, Ingo Molnar <mingo(a)elte.hu> wrote: > > > > > > * KOSAKI Motohiro <kosaki.motohiro(a)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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 9 Dec 2009 04:20
* KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> wrote: > > > > * Bryan Donlan <bdonlan(a)gmail.com> wrote: > > > > > On Tue, Dec 8, 2009 at 12:38 AM, Ingo Molnar <mingo(a)elte.hu> wrote: > > > > > > > > * KOSAKI Motohiro <kosaki.motohiro(a)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. it doesnt. By 'this' i meant the security aspect. ptrace can already do almost arbitrary alteration to any task's state. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |