|
|
Subscribe / Log in / New account

Local root vulnerability in snap-confine

Local root vulnerability in snap-confine

Posted Feb 19, 2022 10:26 UTC (Sat) by intgr (subscriber, #39733)
In reply to: Local root vulnerability in snap-confine by epa
Parent article: Local root vulnerability in snap-confine

> whoever came up with the mountinfo format, but that may be a little unfair as I'm sure it has simply evolved rather than being designed

I don't really blame whoever came up with it, but I blame kernel developers for not offering better alternatives for new use cases and migrating old kludges over.

Kernel developers should decide on a new unambiguous and extensible serialization format for complex nested data structures. In 1990s these lessons hadn't really been learned yet, but in 2022 we have protobuf, Avro, Arrow, ASN.1, JSON and plenty more. I'm sure we can find at least one that suits the kernel use case.

> blame whoever decided that ( ) and space should be legal characters in a mount point path name

This wouldn't even help that much. Restricting characters in path names would solve this particular issue for paths, but there are still plenty of other strings with arbitrary content that may end up being communicated to user space. So would you propose blocking a set of characters in *all* kernel inputs?

I feel like a broken record at this point, but again: if you're having trouble transmitting certain characters in your serialization format, it's the serialization format that sucks.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds