linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Howes <vger.kernel.org@ch.pkts.ca>
To: linux-fsdevel@vger.kernel.org
Subject: Question: How to prefix "../root" to output of readlink in /proc/<pid>/fd/ ?
Date: Mon, 04 May 2020 13:42:06 -0700	[thread overview]
Message-ID: <83e0cb6b9d7c4212dedd2e87c2f73f2c@ch.pkts.ca> (raw)

Hi linux-fsdevel,

When you go into /proc/<pid>/fd and type 'ls -l', you see the numbered 
file descriptors as symlinks to the real files, devices, etc.  Opening 
the file descriptors allows you to access the contents, even if the 
object has already been deleted.

In several virtualized environments (e.g. kubernetes/docker, chroot, 
etc), you can still access the contents, but the target of the symlink 
(output of readlink) is shown as an absolute path from the *virtual* 
root directory.  This may not be the same environment the caller is in, 
resulting in (apparently) broken links.

One solution would be to show the path relative to /proc/<pid>/root 
instead, turning
   "6 -> /some/directory/foo" (broken link)
into
   "6 -> ../root/some/directory/foo" (relative link using process' actual 
root directory),
or possibly
   "6 -> /proc/1234/root/some/directory/foo" (absolute link using actual 
root directory).

Pros:
-----

+ This fixes some (maybe all?) of the erroneously broken links in 
/proc/<pid>/fd
+ This would work for all processes, virtualized or not.
+ It can't break existing code (any further), unless existing code 
depends on erroneously broken links.
+ It's short.

Cons:
-----

- Maybe there is existing code that assumes absolute links instead of 
relative links?

Implementation details:
-----------------------
It looks like adding some code to do_proc_readlink 
(https://github.com/torvalds/linux/blob/690e2aba7beb1ef06352803bea41a68a3c695015/fs/proc/base.c 
) might do the trick; d_path() already appends ' (deleted)' to the link 
if necessary, prepending '../root' to paths that start with '/' should 
work the same way.

Question:
---------
I'd like to write a patch for this, but after reading some of the 
patches in linux-fsdevel, it looks like there are lots of  
implementation details I could get wrong through ignorance of kernel 
internals.  What would you recommend for a good example to copy?

Conversely, if this is a 5-minute job for someone here, would anyone 
like to take it on?

Thanks!

-- 
Charles Howes <vger.kernel.org@ch.pkts.ca>

                 reply	other threads:[~2020-05-04 20:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83e0cb6b9d7c4212dedd2e87c2f73f2c@ch.pkts.ca \
    --to=vger.kernel.org@ch.pkts.ca \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).