> On Wed, 2021-04-14 at 15:29 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > That's fair - if it were possible to get an fd during dump, we could > use fgetxattr. If not, we can use /proc/$pid/exe - even when deleted > you can interact with it: > > [malmond@malmond-x1 ~]$ ls -l /proc/$$/exe > lrwxrwxrwx. 1 malmond malmond 0 Apr 14 15:45 /proc/364665/exe -> > '/home/malmond/testbash (deleted)' > [malmond@malmond-x1 ~]$ attr -l /proc/$$/exe > Attribute "selinux" has a 54 byte value for /proc/364665/exe > > (this is me copying bash, executing it, then deleting it). My thinking > is this could go in systemd-coredump as it's invoked when dumping core > anyway. Libraries are accessible from /proc/$pid/map_files/$range. > > > I'm confused about this - I had put forth an idea for how to make rpm > create this when installing packages (so it works with older or third > party packages) but the same xattr could be created for any packaging > system. Can you clarify what is rpm dependent here? > > Matthew. Hi, There's a few issues with using xattr, some minor and one major. The minor issues is that it's really not great when you are shipping stuff around - the source/transport/medium/archiving format might or might not support it. Having to deal with this for cross-building Linux binaries from Windows with SELinux labels I can assure it's a massive headache I'd rather not replicate :-) The major issue though is a different one, if related: one of the central, nicest capabilities of this proposal is that the ELF note gets _automatically_ included in the generated core file. No change required anywhere for that to happen. This means if you are running a fleet of headless systems, and you collect corefiles on each node and ship them off for offline analysis, all the metadata is nicely included, automagically. That's because the metadata is a property of the binary and assigned at the source, not of the system where it runs on and applied at the destination. If you use xattrs though, the metadata suddenly becomes a property of the system where the binary happens to run on. The core file won't have it. The only way to see it is to have access to the system. It's no longer nicely self-contained and "replicating". Also you are no longer guaranteed to _always_ have the metadata available as long as you add it at build time - suddenly, if your binary ends up installed on the 'wrong' system/container/whatever, because they are too old or don't have a package manager or whatever else, your metadata is gone. And just to clarify, these use cases are not theoretical - they are very much real and already working. And these are the main reasons the team that handles crashdumps at Microsoft suggested adding a '.note' to the ELF rather than a new header or other proposals. I realize this is less of a problem if you look at things exclusively from the closed-loop of a single distribution building its stuff and shipping its installations only, but with this spec and implementation we are trying hard to have a general, 'world-wide' solution that works across distros, version, flavours, etc etc. In this sense, the implementation I contributed to systemd-coredump is ""just"" a reference implementation of how to parse and use the spec, but it's by no means intended to be a systemd-only affair and an internal-only protocol, ending at the new journald fields. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
