Hacker News Reader

Comment by jandrese | Hacker News Reader

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.

View on HN

> 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.

.. but you can just run coredumpctl gdb or coredumpctl dump <the dump> > /tmo/YOLO.dump

This 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)

I'm not at my laptop right now, but from 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?

It's not. It sets ACLs so that the user that owns the process may read the coredump, but typical ls doesn't show that.

ls -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)

Reply on news.ycombinator.com