setproctitle

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/

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

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

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.

-----Original Message-----

Please fix your quoting style.

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

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.

Hi Robert :)

* Robert White <[email protected]> dixit:

[...]

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?

Exactly ;)

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/

Hi William :)

* William Lee Irwin III <[email protected]> dixit:

[...]

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/

* William Lee Irwin III <[email protected]> dixit:

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

-- wli