When the user starts a program which elevates its permissions via setuid, setgid, or capabilities set on the file, it may access additional information which would then be visible in the coredump. We shouldn't make the the coredump visible to the user in such cases. Reported-by: Matthias Gerstner <mgerstner@suse.de> This reads the /proc/<pid>/auxv file and attaches it to the process metadata as PROC_AUXV. Before the coredump is submitted, it is parsed and if either at_secure was set (which the kernel will do for processes that are setuid, setgid, or setcap), or if the effective uid/gid don't match uid/gid, the file is not made accessible to the user. If we can't access this data, we assume the file should not be made accessible either. In principle we could also access the auxv data from a note in the core file, but that is much more complex and it seems better to use the stand-alone file that is provided by the kernel. Attaching auxv is both convient for this patch (because this way it's passed between the stages along with other fields), but I think it makes sense to save it in general. We use the information early in the core file to figure out if the program was 32-bit or 64-bit and its endianness. This way we don't need heuristics to guess whether the format of the auxv structure. This test might reject some cases on fringe architecutes. But the impact would be limited: we just won't grant the user permissions to view the coredump file. If people report that we're missing some cases, we can always enhance this to support more architectures. I tested auxv parsing on amd64, 32-bit program on amd64, arm64, arm32, and ppc64el, but not the whole coredump handling. (cherry picked from commit 3e4d0f6cf99f8677edd6a237382a65bfe758de03) (cherry picked from commit 9b75a3d0502d6741c8ecb7175794345f8eb3827c)
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.