headers
akpm | 5 Mar 2010 22:42

[patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

From: KOSAKI Motohiro <kosaki.motohiro@...>

Currently glibc2 doesn't have setproctitle(3), so several userland daemons
attempt to emulate it by doing some brutal stack modifications.  This
works most of the time, but it has problems.  For example:

 % ps -ef |grep avahi-daemon
 avahi     1679     1  0 09:20 ?        00:00:00 avahi-daemon: running [kosadesk.local]

 # cat /proc/1679/cmdline
 avahi-daemon: running [kosadesk.local]

This looks good, but the process has also overwritten its environment area
and made the environ file useless:

 # cat /proc/1679/environ
 adesk.local]

Another problem is that the process title length is limited by the size of
the environment.  Security conscious people try to avoid potential
information leaks by clearing most of the environment before running a
daemon:

 # env - MINIMUM_NEEDED_VAR=foo /path/to/daemon

The resulting environment size may be too small to fit the wanted process
titles.

This patch makes it possible for userspace to implement setproctitle()
cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
(Continue reading)

Permalink | Reply | 5 comments |
headers
Linus Torvalds | 6 Mar 2010 20:05
Gravatar

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()


On Fri, 5 Mar 2010, akpm@... wrote:
> 
> This patch makes it possible for userspace to implement setproctitle()
> cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> updates task's mm_struct->arg_start and arg_end to the given area.

This looks overly complicated. Why do you change the whole locking rules, 
instead of protecting _only_ the "arg_start/arg_end" case? 

The thing is, there's no reason to hold the mmap_sem over the whole thing, 
and I don't think this is important enough to be a valid reason for 
exposing a whole new "locked" access variant, when a simple "protect just 
the arg_start/end" would handle it.

			Linus
Permalink | Reply | 4 comments |
headers
Oleg Nesterov | 7 Mar 2010 20:28
Picon
Favicon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

On 03/06, Linus Torvalds wrote:
>
> On Fri, 5 Mar 2010, akpm@... wrote:
> >
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
>
> This looks overly complicated. Why do you change the whole locking rules,
> instead of protecting _only_ the "arg_start/arg_end" case?
>
> The thing is, there's no reason to hold the mmap_sem over the whole thing,
> and I don't think this is important enough to be a valid reason for
> exposing a whole new "locked" access variant, when a simple "protect just
> the arg_start/end" would handle it.

It was me who suggested to re-use mm->mmap_sem instead of adding the new
lock, but looking at this patch again I do not understand the reason this
lock should be held throughout in proc_pid_cmdline(). If there is no such
a reason, then the new access_process_vm_locked (cough, also suggested by
me ;) is not needed.

Oleg.
Permalink | Reply | 2 comments |
headers
Bryan Donlan | 7 Mar 2010 21:24
Picon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

On Sun, Mar 7, 2010 at 14:28, Oleg Nesterov <oleg@...> wrote:
> On 03/06, Linus Torvalds wrote:
>>
>> On Fri, 5 Mar 2010, akpm@... wrote:
>> >
>> > This patch makes it possible for userspace to implement setproctitle()
>> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
>> > updates task's mm_struct->arg_start and arg_end to the given area.
>>
>> This looks overly complicated. Why do you change the whole locking rules,
>> instead of protecting _only_ the "arg_start/arg_end" case?
>>
>> The thing is, there's no reason to hold the mmap_sem over the whole thing,
>> and I don't think this is important enough to be a valid reason for
>> exposing a whole new "locked" access variant, when a simple "protect just
>> the arg_start/end" would handle it.
>
> It was me who suggested to re-use mm->mmap_sem instead of adding the new
> lock, but looking at this patch again I do not understand the reason this
> lock should be held throughout in proc_pid_cmdline(). If there is no such
> a reason, then the new access_process_vm_locked (cough, also suggested by
> me ;) is not needed.

Consider:

Process A is reading /proc/pidB/cmdline. As it enters
proc_pid_cmdline, the compiler stashes mm->arg_end and mm->arg_start
in a register or something, and then the process is preempted.
Process B now changes the location of its cmdline buffer. After
changing it, it free()s the buffer. Then it malloc()s a buffer for
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oleg Nesterov | 8 Mar 2010 13:56
Picon
Favicon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

On 03/07, Bryan Donlan wrote:
>
> On Sun, Mar 7, 2010 at 14:28, Oleg Nesterov <oleg@...> wrote:
> > On 03/06, Linus Torvalds wrote:
> >>
> >> On Fri, 5 Mar 2010, akpm@... wrote:
> >> >
> >> > This patch makes it possible for userspace to implement setproctitle()
> >> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> >> > updates task's mm_struct->arg_start and arg_end to the given area.
> >>
> >> This looks overly complicated. Why do you change the whole locking rules,
> >> instead of protecting _only_ the "arg_start/arg_end" case?
> >>
> >> The thing is, there's no reason to hold the mmap_sem over the whole thing,
> >> and I don't think this is important enough to be a valid reason for
> >> exposing a whole new "locked" access variant, when a simple "protect just
> >> the arg_start/end" would handle it.
> >
> > It was me who suggested to re-use mm->mmap_sem instead of adding the new
> > lock, but looking at this patch again I do not understand the reason this
> > lock should be held throughout in proc_pid_cmdline(). If there is no such
> > a reason, then the new access_process_vm_locked (cough, also suggested by
> > me ;) is not needed.
>
> Consider:
>
> Process A is reading /proc/pidB/cmdline. As it enters
> proc_pid_cmdline, the compiler stashes mm->arg_end and mm->arg_start
> in a register or something, and then the process is preempted.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ulrich Drepper | 9 Mar 2010 06:21
Picon
Favicon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()


On 03/08/2010 08:44 PM, KOSAKI Motohiro wrote:
> I don't think this is big matter. Does using syscall have any benefit?
> I don't have strong mention. merely, Timo's original proposal used
> prctl.

Syscalls don't have to go through the multiplexer in grab bag calls like
prctl, ioctl, etc.  And they are more reliably to test for at runtime.
An ENOSYS error is unmistakably clear.  An EINVAL error, as returned by
prctl when encountering an unknown function argument, could also mean
the argument isn't valid.  That's a common problem of most multiplexer
syscalls and a reason why they should be avoided.

--

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Permalink | Reply | 3 comments |
headers
KOSAKI Motohiro | 9 Mar 2010 06:14
Favicon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

> 
> 
> On Fri, 5 Mar 2010, akpm@... wrote:
> > 
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
> 
> This looks overly complicated. Why do you change the whole locking rules, 
> instead of protecting _only_ the "arg_start/arg_end" case? 
> 
> The thing is, there's no reason to hold the mmap_sem over the whole thing, 
> and I don't think this is important enough to be a valid reason for 
> exposing a whole new "locked" access variant, when a simple "protect just 
> the arg_start/end" would handle it.

Hmm..

I did it at several previous iteration. but Alan and Oleg don't like such
approach. After small discussion, we concluded that this reusing mmap_sem doesn't
have unignorable downside.

We discussed this patch need to conder following two performance worrieness.

Q1) The system doesn't have badboy process, it shouldn't have system
    performance degression.
A1) In writer side, setproctitle() is not frequently called function.
    then, performance damage is nothing. In reader side, this patch doesn't
    add to take any new lock.
(Continue reading)

Permalink | Reply | 0 comments |
headers
KOSAKI Motohiro | 9 Mar 2010 05:44
Favicon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

> On Fri, Mar 05, 2010 at 01:42:37PM -0800, akpm@... wrote:
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly.  It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
> 
> Why can't we make this a proper system call?

I don't think this is big matter. Does using syscall have any benefit?
I don't have strong mention. merely, Timo's original proposal used
prctl.
Permalink | Reply | 4 comments |
headers
Oleg Nesterov | 9 Mar 2010 23:17
Picon
Favicon

Re: [patch 050/160] prctl: add PR_SET_PROCTITLE_AREA option for prctl()

On 03/08, Ulrich Drepper wrote:
>
> On 03/08/2010 08:44 PM, KOSAKI Motohiro wrote:
> > I don't think this is big matter. Does using syscall have any benefit?
> > I don't have strong mention. merely, Timo's original proposal used
> > prctl.
>
> Syscalls don't have to go through the multiplexer in grab bag calls like
> prctl, ioctl, etc.  And they are more reliably to test for at runtime.
> An ENOSYS error is unmistakably clear.  An EINVAL error, as returned by
> prctl when encountering an unknown function argument, could also mean
> the argument isn't valid.  That's a common problem of most multiplexer
> syscalls and a reason why they should be avoided.

Agreed, but this applies to any prtcl() request. And we already have
PR_GET_NAME/PR_SET_NAME which is very close to PR_SET_PROCTITLE_AREA.

So, do you really think that this particular case deserves the new
syscall?

Oleg.
Permalink | Reply | 2 comments |

Gmane