Bug 16344 - Linux /proc/PID/map_files/ for deleted files
Summary: Linux /proc/PID/map_files/ for deleted files
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: shlibs (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Blocks: 11579
  Show dependency treegraph
Reported: 2013-12-18 20:16 UTC by Jan Kratochvil
Modified: 2014-03-27 18:27 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2013-12-18 20:16:03 UTC
Backtracing already deleted files does not work:

$ gdb -q -p $p
Attaching to process 12280
.../elfutils/tests/deleted (deleted): No such file or directory.
(gdb) bt
#0  0x472bd360 in ?? ()
Cannot access memory at address 0x2cc946e8

This commonly happens for long-term running processes/daemons which have been nightly automatically upgraded or which have been nightly prelinked by prelink.

But it could work, recent Linux kernels support /proc/PID/map_files/ demonstrated by elfutils use:

Current Linux kernels (3.11.10) permit only root user as the tracer but (1) hopefully it gets fixed in the future and (2) at least for the use in ABRT it is OK as backtracer is run from core dumping hook.

Linux kernels have always supported also /proc/PID/exe which works for deleted main executable.  It even works for non-root users.  But it works only for the executable, not for shared libraries.  I find more useful to push for Linux kernel /proc/PID/map_files/ permissions fix than to implement /proc/PID/exe.
Comment 1 Jan Kratochvil 2014-03-27 18:27:10 UTC
Security discussion of relaxing root-only access to /proc/PID/map_files/:

So far I think /proc/PID/map_files/ will remain root-only accessible.
But one still can access /proc/PID/mem and all the info required for unwinding is present there, future elfutils-0.159 can do it.