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]

Message-ID: <20080812215441.GY28946@ZenIV.linux.org.uk>
Date:	Tue, 12 Aug 2008 22:54:41 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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, Aug 12, 2008 at 02:24:04PM -0700, Linus Torvalds wrote:

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

Tell that to tar(1) ;-)
 
> 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..

I suspect that SUS specifies that crap in some cases, but I honestly do not
remember.  For large offsets, that is.  Large inode numbers are more recent
and hit relatively few filesystems.  OTOH, I suspect that most of getdents()
call sites are in libc anyway...

Anyway, the point for getdents() is simply that we *do* return an error; it's
just that it ends up with -EINVAL instead of -EOVERFLOW, and that's simply
bogus - we should either truncate silently or return the right value.  The
code definitely intends to do the latter and fucks up.
--
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/