Re: setproctitle()

[Timo Sirainen]

On Oct 2, 2009, at 6:53 PM, Bryan Donlan wrote:

> On Fri, Oct 2, 2009 at 5:37 PM, Timo Sirainen <tss@xxxxxx> wrote:
> > I'd like to get BSD's setproctitle() implemented for glibc so that  
> > more
> > programs could start using it. The current method of messing around  
> > with
> > argv and environment to implement it is horribly ugly, fragile and I
> > find it dangerous enough that I haven't dared to use it in my  
> > programs.
> >
> > Any chance of making all this easier so it could actually be  
> > implemented
> > in a generic and safe way in glibc?
>
> Interestingly, there is some code that purports to handle
> setproctitle(): (fs/proc/base.c)
>    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).

Yes, I saw this. It's especially interesting that it mentions  
setproctitle(3), which doesn't exist in Linux.

>    if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
>        len = strnlen(buffer, res);
>        if (len < res) {
>            res = len;
>        } else {
>            len = mm->env_end - mm->env_start;
>            if (len > PAGE_SIZE - res)
>                len = PAGE_SIZE - res;
>            res += access_process_vm(task, mm->env_start, buffer+res,  
> len, 0);
>            res = strnlen(buffer, res);
>        }
>    }
>
> This would seem to allow the argument space to be extended up until
> the end of the environment variable area (although it seems to have a
> bug where it will ignore errors when reading this extra bit!)

That is the ugliness I referred to in my previous mail. It also looks  
to me like if the environment is very small, the process title length  
is also very limited.

> Nevertheless, if one were to insist on a more controllable method, a
> better way might be to simply define a syscall that userspace can use
> to select a new command line buffer. Overwrite mm->arg_end and
> mm->arg_start, and there you go. Of course, the logic over here needs
> to be disabled in this case, as env variables will no longer be found
> immediately after the argument vector.

That sounds good to me. Someone else mentioned prctl(PR_SET_NAME) that  
does something related already, so perhaps a new flag for prctl()?  
Something like: prctl(PR_SET_PROCTITLE, proctitle_start,  
proctitle_end). I could try implementing that this weekend (with my  
almost non-existent kernel coding skills) if no one else wants to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/