[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXXxRksU-YTY8WFJzeET9cWsPKo_=6e9RD=F+TS7xVMyQ@mail.gmail.com>
Date: Thu, 22 Aug 2013 13:48:28 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Willy Tarreau <w@....eu>,
"security@...nel.org" <security@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Brad Spengler <spender@...ecurity.net>
Subject: Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)
On Thu, Aug 22, 2013 at 1:44 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Aug 22, 2013 at 1:22 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> Let me rephrase that: why do we allow these types of lookup to recurse
>> like normal symlinks? I'm proposing that these links immediately
>> terminate lookup [..]
>
> It can nest *inside* a regular symlink. So there should not be any
> recursion of pure /proc style symlink jumps, but they live within the
> nesting that is normal symlink behavior.
>
Sure. But aren't they always last?
With the current code structure, trying to enforce some kind of
security restriction in the middle of lookup seems really unpleasant.
But if the final step is to verify one of these links and then either
reject or end lookup right there, it'll be (IMO) much easier to
understand.
--Andy
> Linus
--
Andy Lutomirski
AMA Capital Management, LLC
--
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/
Powered by blists - more mailing lists