Re: [patch] Support live PIDs with deleted files

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Thu, 19 Dec 2013 14:01:26 +0100, Mark Wielaard wrote:
> Do you have a reference to do documentation of /proc/PID/map_files?
[...]
> But it would be good to see the "official" documentation if there is any
> to make sure we are using the kernel interface/contract as intended.

There is nothing in:
	grep -rw map_files /usr/share/doc/kernel-doc-*/Documentation/

I have found only:
	http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=640708a2cff7f81e246243b0073c66e6ece7e53e
	http://thread.gmane.org/gmane.linux.file-systems/56985
	http://thread.gmane.org/gmane.linux.file-systems/57600
	http://www.securityfocus.com/archive/1/507386/30/0/threaded


> > I find more useful to push for Linux
> > kernel /proc/PID/map_files/ permissions fix than to implement /proc/PID/exe.
> 
> Did you discuss this with the kernel hackers?

Not yet.  The discussions above suggest there should exist a solution with
user-accessible /proc/PID/map_files/ but it is not easy to make it security
safe and as root-only access was sufficient for the use case that time
(=feature checkpoint/restore, whatever that means) they kept it that way.
With a plan to relax the security permissions in the future.

So far I (obviously) also do not see some obvious solution for the kernel
security issue so while I may/will work on it the kernel security permissions
extension will take some time.


> I think it is useful to implement this for /proc/PID/exe first and if
> that works extend it to /proc/PID/map_files if the permission and
> security concerns can be addressed by the kernel people. /proc/PID/exe
> seems to be available everywhere, while /proc/PID/map_files looks very
> recent.

I do not think /proc/PID/exe will make the long-term running live processes
unwinding more useful.  Even if the unwind does not fail on the executable
itself there is even higher probability the unwind fails on any of the shared
libraries present in the backtrace.

As I target the use cases - ABRT core dump time unwinding in this case - GDB
still provides superior functionality over /proc/PID/exe-only elfutils
unwinder (as GDB features the complex non-CFI heuristical unwinder).
So /proc/PID/exe-only extension does not qualify elfutils unwinder as usable
for ABRT while /proc/PID/map_files qualifies it.

I sure can provide also the /proc/PID/exe unwinding although IMO it does not
change much the elfutils unwinder situation.


> I am slightly concerned by the fact that gdb doesn't seem to use this
> mechanism yet. We should at least coordinate usage of this kernel
> feature with them.

I have filed it for GDB in the meantime:
	Linux /proc/PID/map_files/ for deleted files
	https://sourceware.org/bugzilla/show_bug.cgi?id=16344


> Ideally gdb experiments a bit with it and when they
> have found all the quirks we can use it properly :)

This still will leave elfutils unwinder unusable for general (=even long-term
running) live process unwinding.


I will reply the patch details review in a separate mail.


Thanks,
Jan