The rest of the 6.10 merge window [LWN.net]

The rest of the 6.10 merge window

Posted May 28, 2024 17:56 UTC (Tue) by bluca (subscriber, #118303)
In reply to: The rest of the 6.10 merge window by Cyberax
Parent article: The rest of the 6.10 merge window

Usual rubbish. What you, again, fail to understand, is that it's there for free, given there _will_ be multiple processes actively using those APIs, which means the shared library is already loaded in memory by the kernel, and cached among all processes using it. So there is (next to) no extra cost if you don't need it, and if suddenly requirements change and you do need it, you get it for free.

to post comments

The rest of the 6.10 merge window

Posted May 28, 2024 20:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

The question here is not just the overhead (though it IS an issue for containers), but the attack/failure surface. I don't think it's good that every application now has DBUS interface code, just out of pure design cleanliness perspective. Even if it's mostly dormant.

The rest of the 6.10 merge window

Posted May 28, 2024 22:19 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

THIS!

Does this mean any attacker who manages to hijack my program, now has access to DBUS with my credentials?

Not that I understand DBUS in the slightest, but the less code there is in my programs that I don't understand, the happier I am.

And that is actually a real danger - if I'm clueless about DBUS (because I don't knowingly use it), then how am I supposed to defend myself against its misuse (and more to the point - why should I have to)?

Cheers,
Wol

The rest of the 6.10 merge window

Posted May 28, 2024 22:36 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The entire point of arbitrary code execution in a process context is that you can execute arbitrary code, not just whatever code already existed in the process.