linux-kernel - Re: [git pull] vfs.git part 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+55aFyyxJL1LyXZeBsf2ypriraj5ut1XkNDsunRBqgVjZU_6Q@mail.gmail.com>
Date:	Thu, 11 Jul 2013 14:42:54 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] vfs.git part 2

On Wed, Jul 3, 2013 at 5:29 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>         Assorted f_pos race fixes, making do_splice_direct() safe to
> call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series,
> ->d_hash/->d_compare calling conventions changes from Linus, misc stuff
> all over the place.  Please, pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Btw, the new O_TMPFILE support seems to have a fundamental interface
problem: old kernels ignore that flag, and happily implement totally
different semantics than the intended new ones.

So with a *new* kernel, if the filesystem doesn't support O_TMPFILE,
you get an ENOTSUPP error, and you can fall back on whatever old
tmpfile logic you had.

But with an *old* kernel, O_TMPFILE will just silently be ignored as
an unrecognized flag, and things won't work. If you do

  fd = open("dirname", O_CREAT | O_TMPFILE | O_RDWR, 0666);

it may be that it ends up acting as a "create file at specified
directory path" instead of what the user *meant* for it to do, which
was "create unnamed temporary file in the specified directory".

This seems to make the feature actively dangerous. You can't just try
to use it and have a fallback, because that "try to use it" phase may
incorrectly succeed.

Yes, you can force things to not work on old systems by having a slash
at the end of the directory name, but if you ever forget that, you'll
end up with the above problem.

Am I missing something?

              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/