From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754637AbdCTOZ6 (ORCPT ); Mon, 20 Mar 2017 10:25:58 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:36729 "EHLO mail-qt0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753316AbdCTOYQ (ORCPT ); Mon, 20 Mar 2017 10:24:16 -0400 Date: Mon, 20 Mar 2017 07:22:55 -0700 From: Omar Sandoval To: Linus Torvalds Cc: Al Viro , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS Message-ID: <20170320142255.GA28475@vader> References: <20170319172414.GT29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 19, 2017 at 06:46:01PM -0700, Linus Torvalds wrote: > 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". The last posting of the O_BENEATH flag with very similar semantics indicated that there were sandboxing usecases that still want this [1]. I think it's a good idea; the kernel is in the best place to do this correctly instead of having a bunch of half-baked implementations in userspace everywhere. 1: http://marc.info/?l=linux-fsdevel&m=143945842819081&w=2