Is there a reason hard links from /proc/$PID/fd/$NUM are disallowed?

Is there a reason hard links from /proc/$PID/fd/$NUM are disallowed?

[George Spelvin]

I was trying to save a large file that was in mid-download that I had
accidentally deleted (as part of making space in /tmp to hold the file!).

Since it was being held open by the download process, I tried

ln /proc/$PID/fd/$FD /tmp/bigfile.mp4

And got complaints about a cross-device link.

Then I tried cp -l, and got the same error.

Running strace, it appears that cp thinks it should be able to do it,
because the files really *are* on the same file system, but can't:

stat64("/tmp/foo.mp4", 0xbfba74a4)      = -1 ENOENT (No such file or directory)
stat64("/proc/3137/fd/70", {st_mode=S_IFREG|0644, st_size=13796248, ...}) = 0
lstat64("/tmp/foo.mp4", 0xbfba7210)     = -1 ENOENT (No such file or directory)
linkat(AT_FDCWD, "/proc/3137/fd/70", AT_FDCWD, "/tmp/foo.mp4", 0) = -1 EXDEV (Invalid cross-device link)

I notice that other people have tried to do the same thing:
http://lwn.net/Articles/209900/

But generally solutions are based on cp, which is awkward for a file
that's being actively downloaded and will be closed the instant it's
complete.  I really need a hard link.

This seems a silly unnecessary restriction, but before I figure out how
to remove it (I know it'll be FS-specific, but should be easy enough for
tmpfs), is there some important reason why it has to stay?  Are there
some bad security implications to providing this ability?

Now that my panic is over, I realize I could have just done a "sleep
100000 < /proc/$PID/fd/70 &" to hold on to the file descriptor, waited
until the download finished, and copied it *then*.  Or, if I had such a
utility prepared, I could have used a server that held the file open
and provided access to it via FUSE.

So I don't *think* it should allow any new attacks.  But maybe there's
something subtle?

Re: Is there a reason hard links from /proc/$PID/fd/$NUM are disallowed?

[Al Viro]

On Sun, Dec 04, 2011 at 03:40:44PM -0500, George Spelvin wrote:
> I was trying to save a large file that was in mid-download that I had
> accidentally deleted (as part of making space in /tmp to hold the file!).
> 
> Since it was being held open by the download process, I tried
> 
> ln /proc/$PID/fd/$FD /tmp/bigfile.mp4

You do realize that link(2) does *NOT* follow links, do you?  linkat(2)
does, if you explicitly ask for that:

linkat(AT_FDCWD, "/proc/42/fd/1", AT_FDCWD, "/tmp/foo", AT_SYMLINK_FOLLOW)

will do it just fine.

Re: Is there a reason hard links from /proc/$PID/fd/$NUM are disallowed?

[George Spelvin]

> You do realize that link(2) does *NOT* follow links, do you?  linkat(2)
> does, if you explicitly ask for that:
> 
> linkat(AT_FDCWD, "/proc/42/fd/1", AT_FDCWD, "/tmp/foo", AT_SYMLINK_FOLLOW)
> 
> will do it just fine.

Thank you very much!  What's embarrassing is that I actually *knew* that once.

That seems to change the error message.

cd /run/shm	# A tmpfs directory
echo foo > foo
sleep 10000 < foo &
pid=$!
rm foo
strace ln -L /proc/$pid/fd/0 bar

produces:
stat64("/run/shm/bar", 0xbfb7b46c)      = -1 ENOENT (No such file or directory)
stat64("/proc/25098/fd/0", {st_mode=S_IFREG|0644, st_size=4, ...}) = 0
linkat(AT_FDCWD, "/proc/25098/fd/0", AT_FDCWD, "/run/shm/bar", 1024) = -1 ENOENT
 (No such file or directory)

(1024 is indeed AT_SYMLINK_FOLLOW)

It seems to work, however, if the file is *not* deleted first.