3 ms·
Systemd's core dump utility stuffs the files in /var/lib/systemd/coredump with 640 permissions and ownership of root:root regardless of who owned the process.
by jandrese 5y ago
Systemd's core dump utility stuffs the files in /var/lib/systemd/coredump with 640 permissions and ownership of root:root regardless of who owned the process.
It might be paranoia on someone's part, but I agree that it causes a lot of unnecessary privilege escalation for people who want to actually fix the problem.
- pengaru 5y ago> Systemd's core dump utility stuffs the files in /var/lib/systemd/coredump with 640 permissions and ownership of root:root regardless of who owned the process. This isn't true for +ACL builds of systemd, look at the output of `getfacl /var/lib/systemd/coredump/$foo` and you'll see.
- jcelerier 5y ago.. but you can just run coredumpctl gdb or coredumpctl dump <the dump> > /tmo/YOLO.dump
- rwmj 5y agoThis isn't true, at least on Fedora. When my program crashes I run "coredumpctl gdb" without sudo and it works fine - I use this all the time. (It could be that Fedora has done some special configuration and that it's not like this out of the box for upstream systemd)
- e12e 5y agoI'm not at my laptop right now, but from https://www.freedesktop.org/software/systemd/man/coredumpctl.html https://www.freedesktop.org/software/systemd/man/coredumpctl... It looks like coredumpctl might be suid? Or that the service is, and coredumpctl gets access through the service - so there's a certain elevation going on either way?
- lights0123 5y agoIt's not. It sets ACLs so that the user that owns the process may read the coredump, but typical ls doesn't show that.
- deathanatos 5y agols -l will note the presence of ACLs with a "+" next to the permissions. I typically `ls -l` or just have that aliased to ll if it isn't already… (but YMMV)