[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y6xzIR9P+a6uaaEx@itl-email>
Date: Wed, 28 Dec 2022 11:47:25 -0500
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Cc: Alejandro Colomar <alx.manpages@...il.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
linux-kernel@...r.kernel.org, linux-man@...r.kernel.org
Subject: Re: [oss-security] [patch] proc.5: tell how to parse /proc/*/stat
correctly
On Wed, Dec 28, 2022 at 10:24:58AM -0500, Shawn Webb wrote:
> On Tue, Dec 27, 2022 at 04:44:49PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Dominique Martinet writes:
> >
> > > 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.
>
> It would also break forwards compatibility in the case new fields
> needed to be added.
>
> The only solution would be a libxo-style feature wherein a
> machine-parseable format is exposed by virtue of a file extension.
>
> Examples:
>
> 1. /proc/pid/stats.json
> 2. /proc/pid/stats.xml
> 3. /proc/pid/stats.yaml_shouldnt_be_a_thing
A binary format would be even better. No risk of ambiguity.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists