[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20221230201554.xborkqi2x5dvnh6h@jwilk.net>
Date: Fri, 30 Dec 2022 21:15:54 +0100
From: Jakub Wilk <jwilk@...lk.net>
To: <oss-security@...ts.openwall.com>
CC: <linux-man@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [patch] proc.5: tell how to parse /proc/*/stat
correctly
* Tavis Ormandy <taviso@...il.com>, 2022-12-28 01:50:
>>>But, really, I just don't see how this can practically be said to be
>>>parsable...
>>
>>In its current form it never will be. The solution is to place this
>>variable-length field last. Then you can "cut -d ' ' -f 51-" to get
>>the command+args part (assuming I counted all those fields correctly
>>...)
>>
>>Of course, this breaks backwards compatability.
>
>I think that cut command doesn't handle newlines,
Indeed.
>There already is 'ps -q $$ -o >comm='
FWIW, "ps ... -o comm=" doesn't just print the raw comm value: it
replaces non-printable chars with punctuation characters, and it may
append " <defunct>" if the process is a zombie.
The easiest way to get unmangled comm is to read it from
/proc/$PID/comm, then strip the trailing newline.
(But I suspect most /proc/*/stat parsers don't care about the comm field
at all; they just want to skip over it to get their hands on the
following fields.)
--
Jakub Wilk
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
