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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	4 Dec 2011 15:40:44 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux@...izon.com
Subject: Is there a reason hard links from /proc/$PID/fd/$NUM are disallowed?

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/