linux-kernel - Re: setproctitle()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <9ECCBC96-C88C-456B-B8BF-606156461E18@iki.fi>
Date:	Fri, 2 Oct 2009 19:41:13 -0400
From:	Timo Sirainen <tss@....fi>
To:	Bryan Donlan <bdonlan@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: setproctitle()

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

> On Fri, Oct 2, 2009 at 5:37 PM, Timo Sirainen <tss@....fi> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/