Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Dec 2011 10:41:59 -0800
From: Linus Torvalds <>
To: Kees Cook <>
Cc: Andrew Morton <>, Al Viro <>,,,, Randy Dunlap <>, 
	Rik van Riel <>, Federica Teodori <>, 
	Lucian Adrian Grijincu <>, Ingo Molnar <>, 
	Peter Zijlstra <>, Eric Paris <>, 
	Dan Rosenberg <>,
Subject: Re: [PATCH v2011.1] fs: symlink restrictions on sticky directories

On Tue, Dec 6, 2011 at 3:58 PM, Kees Cook <> wrote:
> A long-standing class of security issues is the symlink-based
> time-of-check-time-of-use race, most commonly seen in world-writable
> directories like /tmp.

Ugh. I really dislike the implementation.

Wouldn't it be much nicer to instead actually use the symlink
protection fields, and make the rules be:

 - creating a symlink as root does the traditional "lrwxrwxrwx" thing
 - creating a symlink in a directory you own similarly does "lrwxrwxrwx"
 - creating a symlink anywhere else (which implies either sticky or
world-writable directory) does "lrwx------", so only you can use it.

That seems to be much nicer semantics, and makes the protection
*visible* instead of some kind of hacky run-time random behavior
depending on some invisible config option that people aren't even
aware of.

Of course, it needs to handle renames too (and maybe lchown?), and it
would still need to be an option you enable explicitly, but it seems
much more polite to make things like this something you can actually

No, I have not thought this through deeply, but I really dislike your
kind of "change random semantics in ways that are very hidden and
subtle". The symlink protection approach seems to be much less hidden
and subtle, and should result in largely the same result.

Notably, you can install a system without it on, and turn it on even
after install - who cares if there are *long-term* symlinks with
lrwxrwxrwx and that thus allow all access, it's the racily-created
ones we need to worry about, so it should actually be perfectly ok to
enable the symlink creation protection dynamically. In fact, it could
be a inheritable per-*process* (or per-container) flag rather than a
global flag that says how symlink creation acts.

I dunno.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.