linux-kernel - Re: [RFC] readdir mess

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:	Tue, 12 Aug 2008 14:24:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...IV.linux.org.uk>
cc:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] readdir mess

On Tue, 12 Aug 2008, Al Viro wrote:
> 
> Um...  Here it would happen only on attempt to return an entry for file
> that really has an inumber not fitting into the field; what would you
> do in such case?

You'd truncate the inode number. What's the big deal? Inode numbers aren't 
that important - they're just about the _least_ important part of the data 
returned for a readdir. 

Sure, truncating the inode number may confuse some programs like old-style 
/bin/pwd, but the thing is, we effectively _already_ do that by generating 
essentially random numbers for filesystems that don't have UNIX-style 
inode numbers anyway, so what's the big deal really?

> open() on a huge file is a different story, since you would get a valid 
> opened file and that'd be it; the logics in case of open() is, IIRC, "I 
> guess your binary is old, so it'll probably do other things that would 
> really have to trigger -EOVERFLOW; better bail out right now". 

The thing is, the "probably" is likely "probably not". There's a lot of 
things that work quite well.  Sure, if you lseek() you get confused. If 
you do "stat()" and then mmap(), you'll get confused. But a lot of 
programs really do just read/write. Or use llseek(), in fact. O_LARGEFILE 
is actually a later thing tan llseek() was.

So the problem with EOVERFLOW is that it says that programs shouldn't do 
anything at all because they _may_ do bad things.

And don't get me wrong - I think EOVERFLOW was (and is) actually a good 
thing for the _transition_ period. Exactly because it breaks programs in 
obvious ways, and early. It's good to be annoying in order to find 
problems early and fix them.

But I also think that we're not in a transition period any more, and as a 
result the annoyance part is just annoying an doesn't help find and fix 
problems any more, it just makes legacy binaries not work even if they 
could otherwise work fine (and _maybe_ have problems).

So something that made sense five years ago may not make sense any more, 
is what I'm saying. These days, if somebody runs legacy binaries, they do 
it because of archeology reasons or similar..

			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/