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 12:17:27 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>, Willy Tarreau <w@....eu>,
	Oleg Nesterov <oleg@...hat.com>,
	"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 Sun, Aug 25, 2013 at 11:32 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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.
>

We have fdinfo now, which is IMO much less scary.  Programs can find
the stream position, but they can't change it.  OTOH...

> 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.

.../dev/stdin doesn't actually do what you expect if input comes from
something seekable.

$ cat /proc/self/fd/3
test
$ cat /proc/self/fd/3
test
$ cat /proc/self/fd/3
test
$ cat <&3
est
$ cat /proc/self/fd/3
test
$ cat <&3

(I'm not going to advocate for changing this.)

--Andy

>
>               Linus



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/