setproctitle

setproctitle

[DervishD]

    Hi all :)

    Is there any special reason not to implement setproctitle in the
kernel? In user space is a bit difficult to implement since 'argv[0]'
cannot grow beyond the initially allocated space, better said, it can
grow but only changing the pointer to another place or eating the
space occupied by the other arguments.

    proftpd has a not-very-polite set_proc_title that misses the
final NULL, and a couple of other programs out there uses it, too.
Applications should be free to change theirs proc titles to some
pretty if they want, shouldn't they?

    In proc/base.c you can read about 'setproctitle(3)', that is, in
library space (user space), not kernel space, but AFAIK only FreeBSD
has setproctitle :?

    Thanks in advance :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: setproctitle

[William Lee Irwin III]

On Wed, Aug 18, 2004 at 10:28:51AM +0200, DervishD wrote:
>     Is there any special reason not to implement setproctitle in the
> kernel? In user space is a bit difficult to implement since 'argv[0]'
> cannot grow beyond the initially allocated space, better said, it can
> grow but only changing the pointer to another place or eating the
> space occupied by the other arguments.
>     proftpd has a not-very-polite set_proc_title that misses the
> final NULL, and a couple of other programs out there uses it, too.
> Applications should be free to change theirs proc titles to some
> pretty if they want, shouldn't they?
>     In proc/base.c you can read about 'setproctitle(3)', that is, in
> library space (user space), not kernel space, but AFAIK only FreeBSD
> has setproctitle :?

Observe the following, from fs/proc/base.c:

static int proc_pid_cmdline(struct task_struct *task, char * buffer)
{
	int res = 0;
	unsigned int len;
	struct mm_struct *mm = get_task_mm(task);
	if (!mm)
		goto out;
	if (!mm->arg_end)
		goto out;	/* Shh! No looking before we're done */

 	len = mm->arg_end - mm->arg_start;
 
	if (len > PAGE_SIZE)
		len = PAGE_SIZE;
 
	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).
	if (res > 0 && buffer[res-1] != '\0') {
		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);
		}
	}
	mmput(mm);

out:
	return res;
}

The command-line arguments are being fetched from the process address
space, i.e. simply editing argv[] in userspace will have the desired
effect. Though this code is butt ugly.


-- wli

RE: setproctitle

[Robert White]

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
On Behalf Of William Lee Irwin III
Sent: Wednesday, August 18, 2004 1:59 AM
To: DervishD
Cc: Linux-kernel
Subject: Re: setproctitle

> The command-line arguments are being fetched from the process address
> space, i.e. simply editing argv[] in userspace will have the desired
> effect. Though this code is butt ugly.

What prevents overrun when updating arg[]?

What happens to all the little ps (etc.) programs when I munge together a *really*
*long* title?

Can the entirety of arg[] be moved to a newly allocated region, if so how?  (e.g.
wouldn't I have to have access to overwrite mm->arg_start etc?

I'd prefer a setthreadtitle(char * new_title) such that the individual threads in a
process (including the master thread, and so setproctitle() function is covered)
could be re-titled to declare their purposes.  It would make debugging and logging a
lot easier and/or more meaningful sometimes. 8-)

It would also let the system preserve the original invocation and args for the
lifetime of the process to prevent masquerading.  You know, by default the title is
the args, but the set operation would build the new title in a new kernel-controlled
place and move the pointer.

I'd be willing to work on this if there is interest.

Rob.

Re: setproctitle

[William Lee Irwin III]

-----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
> On Behalf Of William Lee Irwin III
> Sent: Wednesday, August 18, 2004 1:59 AM
> To: DervishD
> Cc: Linux-kernel
> Subject: Re: setproctitle
> > The command-line arguments are being fetched from the process address
> > space, i.e. simply editing argv[] in userspace will have the desired
> > effect. Though this code is butt ugly.

Please fix your quoting style.


On Wed, Aug 18, 2004 at 02:21:36PM -0700, Robert White wrote:
> What prevents overrun when updating arg[]?
> What happens to all the little ps (etc.) programs when I munge
> together a *really* *long* title?
> Can the entirety of arg[] be moved to a newly allocated region, if so
> how?  (e.g. wouldn't I have to have access to overwrite mm->arg_start
> etc?
> I'd prefer a setthreadtitle(char * new_title) such that the individual
> threads in a process (including the master thread, and so
> setproctitle() function is covered) could be re-titled to declare
> their purposes.  It would make debugging and logging a lot easier
> and/or more meaningful sometimes. 8-)
> It would also let the system preserve the original invocation and
> args for the lifetime of the process to prevent masquerading.  You
> know, by default the title is the args, but the set operation would
> build the new title in a new kernel-controlled place and move the
> pointer.
> I'd be willing to work on this if there is interest.

Well, I pointed the code out to you, so you should be all set to find
the answers to these questions and/or implement the proposed changes.
When you have patches for such proposed changes I'll review them then.


-- wli

RE: setproctitle

[Richard B. Johnson]

On Wed, 18 Aug 2004, Robert White wrote:

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
> On Behalf Of William Lee Irwin III
> Sent: Wednesday, August 18, 2004 1:59 AM
> To: DervishD
> Cc: Linux-kernel
> Subject: Re: setproctitle
>
> > The command-line arguments are being fetched from the process address
> > space, i.e. simply editing argv[] in userspace will have the desired
> > effect. Though this code is butt ugly.
>
> What prevents overrun when updating arg[]?
>
> What happens to all the little ps (etc.) programs when I munge together a *really*
> *long* title?
>
> Can the entirety of arg[] be moved to a newly allocated region, if so how?  (e.g.
> wouldn't I have to have access to overwrite mm->arg_start etc?
>
> I'd prefer a setthreadtitle(char * new_title) such that the individual threads in a
> process (including the master thread, and so setproctitle() function is covered)
> could be re-titled to declare their purposes.  It would make debugging and logging a
> lot easier and/or more meaningful sometimes. 8-)
>
> It would also let the system preserve the original invocation and args for the
> lifetime of the process to prevent masquerading.  You know, by default the title is
> the args, but the set operation would build the new title in a new kernel-controlled
> place and move the pointer.
>
> I'd be willing to work on this if there is interest.
>
> Rob.
>

Currently the *argv[], the args themselves, and the environment
are on the stack when _start is called.

#
#	This is the entry point, usually the first thing in the text
#	segment. The SVR4/i386 ABI (pages 3-31, 3-32) says that upon
#	entry most registers' values are unspecified, except for:
#
#   %edx	Contains a function pointer to be registered with `atexit'.
#   		This is how the dynamic linker arranges to have DT_FINI
#		functions called for shared libraries that have been loaded
#		before this code runs.
#
#   %esp	The stack contains the arguments and environment:
#   		(%esp)			argc
#		4(%esp)			argv[0]
#		...
#		(4*argc)(%esp)		NULL
#		(4*(argc+1))(%esp)	envp[0]
#		...
#					NULL

So, overwriting the arguments will destroy the task's copy of
the environment. Fortunately _start code doesn't execute
a return. If it did, the destroyed stack would not contain
anything like a return address. Instead, _start executes the
"exit" system-call after executing any 'atexit' procedures.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: setproctitle

['DervishD']

    Hi Robert :)

 * Robert White <rwhite@casabyte.com> dixit:
> > The command-line arguments are being fetched from the process address
> > space, i.e. simply editing argv[] in userspace will have the desired
> > effect. Though this code is butt ugly.
[...]
> Can the entirety of arg[] be moved to a newly allocated region, if
> so how?  (e.g. wouldn't I have to have access to overwrite
> mm->arg_start etc?

    That was one of the problems I was having: overwriting the memory
you already have is easy, but moving... I mean, you realloc and move
the memory but the kernel doesn't notice it, am I wrong?
 
> I'd prefer a setthreadtitle(char * new_title) such that the
> individual threads in a process (including the master thread, and
> so setproctitle() function is covered) could be re-titled to
> declare their purposes.  It would make debugging and logging a lot
> easier and/or more meaningful sometimes. 8-)

    Exactly ;)
 
> I'd be willing to work on this if there is interest.

    I'm VERY interested, but the problem is that in any case I won't
be able to use that in my programs since portability is sometimes an
issue :( Not all OS are able of such things. The problem, in the end,
is that changing the name of the process is not a standard thing...

    Thanks for your help :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: setproctitle

[DervishD]

    Hi William :)

 * William Lee Irwin III <wli@holomorphy.com> dixit:
> >     In proc/base.c you can read about 'setproctitle(3)', that is, in
> > library space (user space), not kernel space, but AFAIK only FreeBSD
> > has setproctitle :?
> Observe the following, from fs/proc/base.c:
[...]
> The command-line arguments are being fetched from the process address
> space, i.e. simply editing argv[] in userspace will have the desired
> effect. Though this code is butt ugly.

    The problem with this is that is non-portable. Not all Unices
(AFAIK) have this behaviour. The portable solution for changing
argv[0] is to use ONLY the space currently allocated to argv[0]. I
mean, you take argv[0], do a strlen() and overwrite only strlen bytes
of it. The problem with this is that you cannot write an arbitrary
string there. If all Unices provide 'setproctitle' that problem
dissapears.

    Anyway is cool to know that, under Linux, I can change the
argv[0] with no problems.

    Thanks for the help :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: setproctitle

[William Lee Irwin III]

* William Lee Irwin III <wli@holomorphy.com> dixit:
>> The command-line arguments are being fetched from the process address
>> space, i.e. simply editing argv[] in userspace will have the desired
>> effect. Though this code is butt ugly.

On Fri, Aug 20, 2004 at 06:20:27PM +0200, DervishD wrote:
>     The problem with this is that is non-portable. Not all Unices
> (AFAIK) have this behaviour. The portable solution for changing
> argv[0] is to use ONLY the space currently allocated to argv[0]. I
> mean, you take argv[0], do a strlen() and overwrite only strlen bytes
> of it. The problem with this is that you cannot write an arbitrary
> string there. If all Unices provide 'setproctitle' that problem
> dissapears.
>     Anyway is cool to know that, under Linux, I can change the
> argv[0] with no problems.

It is not portable behavior. It is a description of how to implement
setproctitle(3) in Linux.


-- wli

RE: setproctitle

[Albert Cahalan]

> What happens to all the little ps (etc.) programs
> when I munge together a *really* *long* title?

Obviously, ps prints a *really* *long* title.
I suppose, given enough tasks and ps options that
cause sorting, you could run ps out of memory.

> I'd prefer a setthreadtitle(char * new_title) such
> that the individual threads in a process (including
> the master thread, and so setproctitle() function
> is covered) could be re-titled to declare their
> purposes.  It would make debugging and logging a
> lot easier and/or more meaningful sometimes. 8-)

You won't see this in ps output. To save memory
and avoid reading normally-redundant info, ps will
only read the cmdline data once for a process.

You can get the thread ID with "ps -efL", "ps -efT",
"ps -efLm", and so on. That's pretty good. Have it all:

ps -emostat,c,psr,rtprio,class,ppid,pid,tid,nlwp,wchan:9,args

> It would also let the system preserve the original
> invocation and args for the lifetime of the process
> to prevent masquerading.  You know, by default the
> title is the args, but the set operation would
> build the new title in a new kernel-controlled
> place and move the pointer.

Now, this I like.

Solaris stores the first 80 bytes of argv in the
kernel. Modifications do not show up. HP-UX stores
the first 64 bytes, and in recent releases can
also supply a kilobyte of (modified?) argv.