Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761814AbcJRPOe (ORCPT ); Tue, 18 Oct 2016 11:14:34 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:53491 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933588AbcJRPOZ (ORCPT ); Tue, 18 Oct 2016 11:14:25 -0400 Message-Id: <1476803664.765771.759750513.10771FBF@webmail.messagingengine.com> X-Sasl-Enc: W/fm2xbBA2JQFa9i9AjyKjc9yl+sRl4JJDJzKy/wagDX 1476803664 From: Colin Walters To: Mattias Nissler , Al Viro Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2518523d Subject: Re: [RFC] [PATCH] Add a "nolinks" mount option. Date: Tue, 18 Oct 2016 11:14:24 -0400 In-Reply-To: References: <1476455305-35554-1-git-send-email-mnissler@chromium.org> <20161014145515.GA19539@ZenIV.linux.org.uk> <20161014150017.GB19539@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1247 Lines: 28 On Mon, Oct 17, 2016, at 09:02 AM, Mattias Nissler wrote: > OK, no more feedback thus far. Is there generally any interest in a > mount option to avoid path name aliasing resulting in target file > confusion? Perhaps a version that only disables symlinks instead of > also hard-disabling files hard-linked to multiple locations (those are > much lower risk for the situation I care about)? So the situation here is a (privileged) process that is trying to read/write to a filesystem tree writable by other processes that are in a separate security domain? That's a classic situation that requires extreme care, and I am doubtful that symlinks are the only issue you're facing. For example, if this process is also *parsing* any data there, there's another whole source of risk. I suspect for you it wouldn't be too hard to have a "follow untrusted path" helper function, it's possible to implement in userspace safely with O_NOFOLLOW etc. Regardless too, it sounds like what you want more is a "same filesystem" traversal (stat and compare devices). Or does it even need to handle full traversal? Would it have mitigated the security issue to fstat() any files you opened and verified they were from the writable partition you expected?