From: William Lee Irwin III <wli@holomorphy.com>
To: DervishD <disposable1@telefonica.net>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: setproctitle
Date: Wed, 18 Aug 2004 01:58:50 -0700 [thread overview]
Message-ID: <20040818085850.GW11200@holomorphy.com> (raw)
In-Reply-To: <20040818082851.GA32519@DervishD>
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
next prev parent reply other threads:[~2004-08-18 8:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-18 8:28 setproctitle DervishD
2004-08-18 8:58 ` William Lee Irwin III [this message]
2004-08-18 21:21 ` setproctitle Robert White
2004-08-18 21:28 ` setproctitle William Lee Irwin III
2004-08-18 21:46 ` setproctitle Richard B. Johnson
2004-08-20 16:23 ` setproctitle 'DervishD'
2004-08-20 16:20 ` setproctitle DervishD
2004-08-20 16:33 ` setproctitle William Lee Irwin III
-- strict thread matches above, loose matches on Subject: below --
2004-08-19 1:04 setproctitle Albert Cahalan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040818085850.GW11200@holomorphy.com \
--to=wli@holomorphy.com \
--cc=disposable1@telefonica.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox