Re: [RFC] exec: add a flag for "reasonable" execveat() comm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tycho Andersen <tycho@tycho.pizza> writes:

> Yep, I did this for the test above, and it worked fine:
>
>         if (bprm->fdpath) {
>                 /*
>                  * If fdpath was set, execveat() made up a path that will
>                  * probably not be useful to admins running ps or similar.
>                  * Let's fix it up to be something reasonable.
>                  */
>                 struct path root;
>                 char *path, buf[1024];
>
>                 get_fs_root(current->fs, &root);
>                 path = __d_path(&bprm->file->f_path, &root, buf, sizeof(buf));
>
>                 __set_task_comm(me, kbasename(path), true);
>         } else {
>                 __set_task_comm(me, kbasename(bprm->filename), true);
>         }
>
> obviously we don't want a stack allocated buffer, but triggering on
> ->fdpath != NULL seems like the right thing, so we won't need a flag
> either.
>
> The question is: argv[0] or __d_path()?

You know.  I think we can just do:

	BUILD_BUG_ON(DNAME_INLINE_LEN >= TASK_COMM_LEN);
	__set_task_comm(me, bprm->file->f_path.dentry->d_name.name, true);

Barring cache misses that should be faster and more reliable than what
we currently have and produce the same output in all of the cases we
like, and produce better output in all of the cases that are a problem
today.

Does anyone see any problem with that?

Eric




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux