linux-kernel - Re: [RFC] a corner case of open(2)

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 26 Apr 2016 21:17:57 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Valdis.Kletnieks@...edu
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] a corner case of open(2)

On Tue, Apr 26, 2016 at 03:25:16PM -0400, Valdis.Kletnieks@...edu wrote:
> Gaah.. I lost a few words in there - /bin/ls is *expecting* to operate on
> a directory, so to calls getdents.   I meant some generic program that
> opened a directory in error, and was expecting to act on "stream of bytes"
> 
> > We also do not allow opening directories for *write*, and in that case EISDIR
> > is the right error (and we do return it).
> 
> OK, that and ftruncate() are about the only ways to cause trouble with a
> directory opened by accident...

ftruncate() requires the file to be opened for write (which already excludes
directories) *and* it requires the file to be a regular one (which is
redundant in case of directories, but e.g. a block device can be opened
for write and ftruncate would still fail on that).  EINVAL in both cases.

truncate() for directories should fail with EISDIR (see vfs_truncate());
for anything that is neither directory nor regular - EINVAL (same place).

O_TRUNC ends up failing with EISDIR on directories - see
        /* O_TRUNC implies we need access checks for write permissions */
        if (flags & O_TRUNC)
                acc_mode |= MAY_WRITE;
in build_open_flags() and aforementioned bit in may_open().  POSIX is
bloody vague on that topic, but that's the common behaviour since 4.3BSD
has fixed an fs-corrupting bug in the original implementation (4.2BSD
allowed open(directory, O_TRUNC), which both succeeded *and* truncated the
damn thing to zero, to great joy of fsck).  Note that v7 didn't have O_TRUNC
at all - creat(2) was the only way to get it and that opened the sucker r/w,
so the usual rules re "no opening directories for write" applied.  When
O_TRUNC had been introduced, initially they'd missed the possibility of
somebody passing it to read-only open() and the need to reject those for
directories same as open for write.