This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter
- From: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>
- Date: Fri, 20 Mar 2015 22:02:17 +0000
- Subject: Re: [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter
- Authentication-results: sourceware.org; auth=none
- References: <1426807358-18295-1-git-send-email-sergiodj at redhat dot com> <1426807358-18295-2-git-send-email-sergiodj at redhat dot com> <550C7118 dot 6080605 at redhat dot com> <87vbhvwi7x dot fsf at redhat dot com>
On 03/20/2015 08:02 PM, Sergio Durigan Junior wrote:
>>> >> + It is worth mentioning that, from all those checks described
>>> >> + above, the most fragile is the one to see if the file name ends
>>> >> + with " (deleted)". This does not necessarily mean that the
>>> >> + mapping is anonymous, because the deleted file associated with
>>> >> + the mapping may have been a hard link to another file, for
>>> >> + example. The Linux kernel checks to see if "i_nlink == 0", but
>>> >> + GDB cannot easily do this check. Therefore, we made a compromise
>> >
>> > Cannot do it easily, or cannot do it at all?
> It cannot do it easily. If GDB is run by root, then it could (in
> theory) inspect the contents of /proc/PID/map_files and determine
> whether the " (deleted)" file was a hard link or not.
Ah, could you include that in the comment please?
Otherwise every time I read that I'll wonder what wasn't easy. :-)
Like:
"(..) example. The Linux kernel checks to see if "i_nlink == 0", but
GDB cannot easily (and normally) do this check (iff running as root,
it could find the mapping in /proc/PID/map_files/ and determine
whether there still are other hard links to the inode/file).
Therefore, we made a compromise (...)"
I quickly tried something like that with "/proc/pid/fd/*", and
unfortunately the link count is always 1, at least on F20's kernel:
$ tail > a&
[1] 12343
[1]+ Stopped tail > a
$ ls -l a
-rw-rw-r--. 1 pedro pedro 0 Mar 20 21:29 a
$ ln a b
$ ls -l a
-rw-rw-r--. 2 pedro pedro 0 Mar 20 21:29 a
$ ls -l /proc/12343/fd/1
l-wx------. 1 pedro pedro 64 Mar 20 21:30 /proc/12343/fd/1 -> /tmp/a
If map_files/ works the same, I think we'd have to get the
file's inode number, and look over the whole filesystem for
other files with that inode number (the equivalent
of 'ls -i' 'find / -inum'). Urgh!
Anyway, with the comment tweak, the patch looks good to me. Thanks
again for doing this.
Thanks,
Pedro Alves