| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <875yll1fp1.fsf@stepbren-lnx.us.oracle.com>
Date: Tue, 31 May 2022 15:48:42 -0700
From: Stephen Brennan <stephen.s.brennan@...cle.com>
To: Kalesh Singh <kaleshsingh@...gle.com>
Cc: Ioannis Ilkos <ilkos@...gle.com>,
"T.J. Mercier" <tjmercier@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
"Cc: Android Kernel" <kernel-team@...roid.com>,
Jonathan Corbet <corbet@....net>,
Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>,
Christoph Anton Mitterer <mail@...istoph.anton.mitterer.name>,
Johannes Weiner <hannes@...xchg.org>,
Colin Cross <ccross@...gle.com>,
Mike Rapoport <rppt@...nel.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Randy Dunlap <rdunlap@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
DRI mailing list <dri-devel@...ts.freedesktop.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@...ts.linaro.org>
Subject: Re: [PATCH 2/2] procfs: Add 'path' to /proc/<pid>/fdinfo/
Kalesh Singh <kaleshsingh@...gle.com> writes:
> On Tue, May 31, 2022 at 3:07 PM Stephen Brennan
> <stephen.s.brennan@...cle.com> wrote:
>>
>> On 5/31/22 14:25, Kalesh Singh wrote:
>> > In order to identify the type of memory a process has pinned through
>> > its open fds, add the file path to fdinfo output. This allows
>> > identifying memory types based on common prefixes. e.g. "/memfd...",
>> > "/dmabuf...", "/dev/ashmem...".
>> >
>> > Access to /proc/<pid>/fdinfo is governed by PTRACE_MODE_READ_FSCREDS
>> > the same as /proc/<pid>/maps which also exposes the file path of
>> > mappings; so the security permissions for accessing path is consistent
>> > with that of /proc/<pid>/maps.
>>
>> Hi Kalesh,
>
> Hi Stephen,
>
> Thanks for taking a look.
>
>>
>> I think I see the value in the size field, but I'm curious about path,
>> which is available via readlink /proc/<pid>/fd/<n>, since those are
>> symlinks to the file themselves.
>
> This could work if we are root, but the file permissions wouldn't
> allow us to do the readlink on other processes otherwise. We want to
> be able to capture the system state in production environments from
> some trusted process with ptrace read capability.
Interesting, thanks for explaining. It seems weird to have a duplicate
interface for the same information but such is life.
>>
>> File paths can contain fun characters like newlines or colons, which
>> could make parsing out filenames in this text file... fun. How would your
>> userspace parsing logic handle "/home/stephen/filename\nsize:\t4096"? The
>> readlink(2) API makes that easy already.
>
> I think since we have escaped the "\n" (seq_file_path(m, file, "\n")),
I really should have read through that function before commenting,
thanks for teaching me something new :)
Stephen
> then user space might parse this line like:
>
> if (strncmp(line, "path:\t", 6) == 0)
> char* path = line + 6;
>
>
> Thanks,
> Kalesh
>
>>
>> Is the goal avoiding races (e.g. file descriptor 3 is closed and reopened
>> to a different path between reading fdinfo and stating the fd)?
>>
>> Stephen
>>
>> > Signed-off-by: Kalesh Singh <kaleshsingh@...gle.com>
>> > ---
>> >
>> > Changes from rfc:
>> > - Split adding 'size' and 'path' into a separate patches, per Christian
>> > - Fix indentation (use tabs) in documentaion, per Randy
>> >
>> > Documentation/filesystems/proc.rst | 14 ++++++++++++--
>> > fs/proc/fd.c | 4 ++++
>> > 2 files changed, 16 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
>> > index 779c05528e87..591f12d30d97 100644
>> > --- a/Documentation/filesystems/proc.rst
>> > +++ b/Documentation/filesystems/proc.rst
>> > @@ -1886,14 +1886,16 @@ if precise results are needed.
>> > 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file
>> > ---------------------------------------------------------------
>> > This file provides information associated with an opened file. The regular
>> > -files have at least five fields -- 'pos', 'flags', 'mnt_id', 'ino', and 'size'.
>> > +files have at least six fields -- 'pos', 'flags', 'mnt_id', 'ino', 'size',
>> > +and 'path'.
>> >
>> > The 'pos' represents the current offset of the opened file in decimal
>> > form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the
>> > file has been created with [see open(2) for details] and 'mnt_id' represents
>> > mount ID of the file system containing the opened file [see 3.5
>> > /proc/<pid>/mountinfo for details]. 'ino' represents the inode number of
>> > -the file, and 'size' represents the size of the file in bytes.
>> > +the file, 'size' represents the size of the file in bytes, and 'path'
>> > +represents the file path.
>> >
>> > A typical output is::
>> >
>> > @@ -1902,6 +1904,7 @@ A typical output is::
>> > mnt_id: 19
>> > ino: 63107
>> > size: 0
>> > + path: /dev/null
>> >
>> > All locks associated with a file descriptor are shown in its fdinfo too::
>> >
>> > @@ -1920,6 +1923,7 @@ Eventfd files
>> > mnt_id: 9
>> > ino: 63107
>> > size: 0
>> > + path: anon_inode:[eventfd]
>> > eventfd-count: 5a
>> >
>> > where 'eventfd-count' is hex value of a counter.
>> > @@ -1934,6 +1938,7 @@ Signalfd files
>> > mnt_id: 9
>> > ino: 63107
>> > size: 0
>> > + path: anon_inode:[signalfd]
>> > sigmask: 0000000000000200
>> >
>> > where 'sigmask' is hex value of the signal mask associated
>> > @@ -1949,6 +1954,7 @@ Epoll files
>> > mnt_id: 9
>> > ino: 63107
>> > size: 0
>> > + path: anon_inode:[eventpoll]
>> > tfd: 5 events: 1d data: ffffffffffffffff pos:0 ino:61af sdev:7
>> >
>> > where 'tfd' is a target file descriptor number in decimal form,
>> > @@ -1968,6 +1974,7 @@ For inotify files the format is the following::
>> > mnt_id: 9
>> > ino: 63107
>> > size: 0
>> > + path: anon_inode:inotify
>> > inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d
>> >
>> > where 'wd' is a watch descriptor in decimal form, i.e. a target file
>> > @@ -1992,6 +1999,7 @@ For fanotify files the format is::
>> > mnt_id: 9
>> > ino: 63107
>> > size: 0
>> > + path: anon_inode:[fanotify]
>> > fanotify flags:10 event-flags:0
>> > fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003
>> > fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4
>> > @@ -2018,6 +2026,7 @@ Timerfd files
>> > mnt_id: 9
>> > ino: 63107
>> > size: 0
>> > + path: anon_inode:[timerfd]
>> > clockid: 0
>> > ticks: 0
>> > settime flags: 01
>> > @@ -2042,6 +2051,7 @@ DMA Buffer files
>> > mnt_id: 9
>> > ino: 63107
>> > size: 32768
>> > + path: /dmabuf:
>> > count: 2
>> > exp_name: system-heap
>> >
>> > diff --git a/fs/proc/fd.c b/fs/proc/fd.c
>> > index 464bc3f55759..8889a8ba09d4 100644
>> > --- a/fs/proc/fd.c
>> > +++ b/fs/proc/fd.c
>> > @@ -60,6 +60,10 @@ static int seq_show(struct seq_file *m, void *v)
>> > seq_printf(m, "ino:\t%lu\n", file_inode(file)->i_ino);
>> > seq_printf(m, "size:\t%lli\n", (long long)file_inode(file)->i_size);
>> >
>> > + seq_puts(m, "path:\t");
>> > + seq_file_path(m, file, "\n");
>> > + seq_putc(m, '\n');
>> > +
>> > /* show_fd_locks() never deferences files so a stale value is safe */
>> > show_fd_locks(m, file, files);
>> > if (seq_has_overflowed(m))
>>
>> --
>> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@...roid.com.
>>
Powered by blists - more mailing lists