linux-kernel - Re: /proc/pid/fd && anon_inode

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 25 Aug 2013 11:32:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Willy Tarreau <w@....eu>, Oleg Nesterov <oleg@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	"security@...nel.org" <security@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Brad Spengler <spender@...ecurity.net>
Subject: Re: /proc/pid/fd && anon_inode_fops

On Sat, Aug 24, 2013 at 10:23 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> We are really stuck with the current semantics here - switching to
> *BSD one would not only mean serious surgery on descriptor handling
> (it's one of the wartier areas in *BSD VFS, in large part because
> of magic-open-really-a-dup kludges they have to do), it would change
> a long-standing userland API that had been there for nearly 20 years
> _and_ one that tends to be used in corner cases of hell knows how many
> scripts.

Actually, I'm pretty sure we did have the "dup" semantics at one point
(long ago), and they were really nice (because you could use them to
see where in the stream the fd was etc). It just fit so horribly badly
into the VFS semantics that it got changed into the current "new file
descriptor" one. Afaik, nothing broke.

So I'm not really sure about the "we're stuck with it" for semantic
reasons, and it turns out that very few programs/scripts actually use
/proc/<pid>/fd/<nr> at all (random use of /dev/stdin is likely the
most common case). But I agree about the "serious surgery on
descriptor handling" part.

              Linus
--
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/