From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH) Date: Thu, 22 Aug 2013 13:22:17 -0700 Message-ID: References: <20130822185317.GI31117@1wt.eu> <20130822201530.GL31117@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Linus Torvalds , "security@kernel.org" , Ingo Molnar , Linux Kernel Mailing List , Oleg Nesterov , Al Viro , Linux FS Devel , Brad Spengler To: Willy Tarreau Return-path: In-Reply-To: <20130822201530.GL31117@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Aug 22, 2013 at 1:15 PM, Willy Tarreau wrote: > On Thu, Aug 22, 2013 at 01:10:43PM -0700, Andy Lutomirski wrote: >> What's the point of nd_jump_link anyway? The only way I can think of >> for a magic symlink in /proc to point to another symlink is to open a >> symlink with O_PATH | O_NOFOLLOW. Actually trying to use the >> resulting link in /proc results in -ELOOP. (Even just trying to open >> a normal symlink with O_NOFOLLOW and without O_PATH results in >> -ELOOP.) > > It's not only that, it also supports sockets and pipes that you can access > via /proc/pid/fd and not via a real symlink which would try to open eg > "pipe:[23456]" instead of the real file. So you can't get rid of it > without breaking existing apps (starting with your shell for which > /dev/stdin is a link to /proc/self/fd/0 for example). > 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 and return back to user_path_at_empty, which can, in turn, do an extra check to see if the inode that was found is one of these magic inodes (or checks to see if nd_jump_link was called). user_path_at_empty could then enforce LOOKUP_EMPTY-list restrictions (or the caller could). --Andy