[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxqdV6CQ8UWkB1Z7HUB9GmRH4Jpw_UmmFqDqG01_DmsWw@mail.gmail.com>
Date: Thu, 22 Aug 2013 13:54:15 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...capital.net>
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:48 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> Sure. But aren't they always last?
What do you mean? I'd say that the /proc lookup is always *innermost*.
Which means that it certainly cannot bail out, since there are many
levels of nesting outside of it.
> With the current code structure, trying to enforce some kind of
> security restriction in the middle of lookup seems really unpleasant.
If it's conditional (ie "linkat behaves differently from openat"), it
certainly means that we'd have to pass in that info in annoying ways.
But having unconditional rules like "you can only follow the proc link
if you have CAP_SEARCH _or_ you match the file->f_cred" doesn't sound
too painful.
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/
Powered by blists - more mailing lists