Description of problem: If systemd-coredump is enabled, core dumps are stolen away from unprivileged users and a privileged user must intercede to transfer the core dump back to the unprivileged user. Version-Release number of selected component (if applicable): systemd-231-10.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1. Crash something. Actual results: As the unprivileged user that caused the core dump: [nicholas@entropy ~]$ coredumpctl No coredumps found. As root: [root@entropy ~]# coredumpctl | tail -n 1 Mon 2016-12-05 17:51:00 PST 17586 500 500 11 * /home/nicholas/src/bitbucket/crash Expected results: Unprivileged users have permission to access their own core dumps.
Does 'journalctl' as that unprivileged user display anything at all?
Yes, but the most recent log entry is from 2014. SplitMode is commented out in /etc/systemd/journald.conf. (Actually, everything is commented out in journald.conf.)
getfacl -p /var/log/journal/$(cat /etc/machine-id)/user-$(id -u).journal ? ls -l /var/log/journal/$(cat /etc/machine-id)/user-$(id -u)*.journal ?
$ getfacl -p /var/log/journal/$(cat /etc/machine-id)/user-$(id -u).journal # file: /var/log/journal/f166f6cdb9985e6faf368fca00000020/user-500.journal # owner: root # group: systemd-journal user::rwx user:nicholas:r-- group::r-x group:adm:r-x group:wheel:r-x mask::r-x other::r-x $ ls -l /var/log/journal/$(cat /etc/machine-id)/user-$(id -u)*.journal -rwxr-xr-x+ 1 root systemd-journal 24M Dec 9 2014 /var/log/journal/f166f6cdb9985e6faf368fca00000020/user-500.journal
OK, that's unfortunate fallout from the change to bump system uid range to 0-1000. systemd has a hardcoded threshold below which users are treated as system users and do not get a separate journal file. This threshold is determined at compile time from /etc/login.defs, and on current Fedora installations it's 1000, so your user with uid=500 is misclasified. We didn't handle this transition very well, but it was a while ago, and it's too late to change that. There are workaround that you can use: the two simplest are to either renumber your user to 1000+, or add your user to the adm group to give it access to system logs. I'll close this because it's a corner case that we missed, but for which no nice solutions exist.
The correct solution is to stop hardcoding the the 0-1000 range and load the value from /etc/login.defs at runtime like you're supposed to. Reading Features/1000SystemAccounts: * logins.def is the authoritative definition of UID/GID space allocations, so systemd hardcoding the (wrong) value is a bug. * Upgrades retaining the boundary value 500 should not break. I don't understand how extracting a runtime configuration value in order to hard code it at build time ever got merged into systemd, that is code smell that stinks to high heaven.
Feel free to take this upstream. As the maintainers of systemd in Fedora, we're not going to deviate from upstream on that. And please don't play bugzilla ping-pong with me: don't reopen this bug unless you have *new* data.
I think the experts have made commendable efforts for RedHat N10-007 dumps https://www.dumpstool.com/RH133-exam.html . And that DumpsTool.com deserves appreciation for doing such great work. I made RedHat N10-007 question answers my choice and prepared my secure very high grades and I’m happy with this.
To do this, invite a strict father to a duel. Karaoke duel. https://friday-nightfunkin.io Prove that you are worthy of his adorable daughter, make the impression of a brave, talented guy.
Thank you for providing such useful information. I've been having trouble coming up with many questions about this topic. I'll stick with https://paperio2.online you!