3 ms·
> Why is it not run as a dedicated core dump user? You could imagine an API that sets the UID of this user, and the kernel could easily run the coredump handle
by rwmj 1y ago
> Why is it not run as a dedicated core dump user?
You could imagine an API that sets the UID of this user, and the kernel could easily run the coredump handler as that user, but the kernel can't so easily automate the creation of a complicated namespace to contain that process (and the process can't do it itself because it could be exploited before it gets around to it). Look at the code in runc some time to see how complicated setting up a namespace has got.
> one probably wants to have shared infrastructure for crash reporting anyways
Not really on a single machine. coredumpctl actually works very well for solo development, I use it all the time.
- nolist_policy 1y agoYou're thinking to complicated. You can configure the coredump helper in a way that the kernel presents it with the coredump on stdin. So you drop privileges and self-sandbox at startup and only then start reading the coredump from stdin. IIUC Ubuntu and systemd however choose to dump the process manually for some reason and for that you need to have same permission as the target process.
- pkhuong 1y ago> start reading the coredump from stdin How does that work with multi-TB mappings, as used by niche functionality like asan?
- nolist_policy 1y agoThe coredump is sparse in elf format.
- charcircuit 1y ago>You could imagine an API that sets the UID of this user No, I think there should be a dedicated user. People will configure it in insecure ways if you let them. >easily automate the creation of a complicated namespace to contain that process Why is this being done. The core dump has already been created. >coredumpctl actually works Coredumpctl would still be possible without forwarding.