From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752827AbdCTBqF (ORCPT ); Sun, 19 Mar 2017 21:46:05 -0400 Received: from mail-it0-f45.google.com ([209.85.214.45]:35778 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752151AbdCTBqD (ORCPT ); Sun, 19 Mar 2017 21:46:03 -0400 MIME-Version: 1.0 In-Reply-To: <20170319172414.GT29622@ZenIV.linux.org.uk> References: <20170319172414.GT29622@ZenIV.linux.org.uk> From: Linus Torvalds Date: Sun, 19 Mar 2017 18:46:01 -0700 X-Google-Sender-Auth: y1SpBiVYW6XAg2GEIzuPIibLQRg Message-ID: Subject: Re: [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS To: Al Viro Cc: Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 19, 2017 at 10:24 AM, Al Viro wrote: > Bringing back an old conversation - what do you think about the > potential usefulness of the following ...at() option: > * no mountpoint crossings allowed (mount --bind included) > * only relative symlinks traversals are allowed > * starting point acts as a chroot boundary (IOW, .. does not lead > out of it) Hmm. The original use of this was iirc apache (or maybe samba), that simply wanted to be sure that when you did a pathname lookup, it didn't escape out of the subtree that the lookup was done from (eg some public_html directory or whatever). But I had that discussions *long* ago, and I don't even remember who it might have been with. My reaction at the time was simply that it would have been easy for us to have a "no symlink traversal at all" mode, because their solution was to just walk each path component carefully by hand. Maybe somebody who knows apache (or samba) can pipe up and say "yeah, we still do that", or "we solved it with our own filename cache, so we don't care". > IIRC, you mentioned that something of that kind might be interesting for > git et.al. and it turns out to be surprisingly easy to implement - So for git, we have a notion of "real path", and your thing doesn't solve that, because it really is "return the actual canonical path to the filename given by xyz". And _usually_ the real path of xyz is trivially xyz. But if xyz contains a symlink, or if xyz contains a "..", that gets resolved. But that needs to happen even *if* the path stays inside the project. So git *could* make use of something that errored out for anything that wasn't canonical: that includes using "." and "" in the pathname, btw, but also symlinks and "..". That would meke the "realpath()" logic be: - try to look it up using the "strict canonical case only", and if that succeeds, we just return the original pathname - otherwise do the per-component lookup and fix it up manually. So for git, escaping the subdirectory is only one small issue, and your patch wouldn't be sufficient because it still allows symlinks that don't escape the tree. (Also, honestly, I don't think it's ever a real performance issue, and since git would need to have the fallback code to do the resolution anyway, it doesn't help from a complexity standpoint either). So I don't think the patch is interesting for git at least as-is, and because of complexity and portability, possibly not even if it did add a flag to always error out on the special path components of "", ".", "..", and symlinks. I think the concept makes sense, and we might well want to encourage it as a way for people to efficiently and easily verify that the end result of a lookup stays inside a certain directory structure, but I think we'd want to have a champion of this feature that would actually use it. Maybe somebody on fsdevel knows of a particular load that is performance-critical and important for some group of people, and currently looks up pathnames component by component because of issues like this.. Anybody? Linus