On 12/30/2009 03:23 PM, akpm@xxxxxxxxxxxxxxxxxxxx wrote: > ------------------------------------------------------ > Subject: prctl: add PR_SET_PROCTITLE_AREA option for prctl() > From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> > > 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 > updates task's mm_struct->arg_start and arg_end to the given area. > Sorry for the late feedback... On the subject of this patch: would it also make sense to have a prctl() to give the kernel the address of the "environ" variable, so that /proc/*/environ can give the *current* environment inside the process (which is otherwise strictly a user-space matter) as opposed to the initial environment passed by the kernel (unless modified in-place)? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
