Re: [patch] proc.5: tell how to parse /proc/*/stat correctly

[Jeffrey Walton <noloader () gmail com>]

On Thu, Dec 29, 2022 at 12:58 PM David A. Wheeler <dwheeler () dwheeler com> wrote:
> > On Dec 29, 2022, at 11:43 AM, Alan Coopersmith <alan.coopersmith () oracle com> wrote:
>
> Another solution is to escape bytes that might cause trouble in this field, e.g., using %xx hexadecimal.
> So space would be %20, ")" would be %41, control characters 1-31 would be %01 to %1f,
> and (of course) "%" would be encoded as %25.
> Basically, URL-encode / Percent-encode them. See: https://en.wikipedia.org/wiki/Percent-encoding

Would you need a full blown encoder?

I was thinking along those lines, but pick a delimiter and only encode
the delimiter when it is present in the data. For example, use the
pipe as a delimiter.

Encoding the space character alone when it is present in the data may
also work. Once a string is parsed based on whitespace, decode the
percent-encoded spaces in the field.

Using \0 as the delimiter would still require encoding of \0 when it
is present in the data.

I guess the question is, do parsers need control characters (<= 0x1f)
encoded or not? If existing parsers can currently handle control
characters, then a full blown encoder may not be needed.

> Technically this would be a userspace change, but only in cases where the system
> would probably have done the wrong thing previously. It's okay if we break *attacker* workflows
> as long as we don't break others'. An advantage of URL encoding is that,
> like JSON, it's a well-known format. I might do something different if this was a new system,
> but that seems like the least-impact approach while eliminating the problem.

I know David did not suggest JSON, but please, no JSON. Use a simple
encoder/decoder like URL-encoding. A URL encoder is easy to implement
in C. JSON is more complex, and developers would probably want/need a
third-party library to do it. There's no sense in gratuitously
broadening the dependency tree.

Jeff