From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [RFC] Privilege escalation in filesystems Date: Thu, 10 Aug 2006 15:45:19 -0400 Message-ID: <1155239119.5826.12.camel@localhost> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Josef Sipek , dpquigl@tycho.nsa.gov, dquigley@ic.sunysb.edu, ezk@cs.sunysb.edu, Christoph Hellwig , linux-fsdevel@vger.kernel.org, Al Viro Return-path: Received: from pat.uio.no ([129.240.10.4]:4775 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S932661AbWHJTpv (ORCPT ); Thu, 10 Aug 2006 15:45:51 -0400 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2006-08-10 at 11:06 -0700, Bryan Henderson wrote: > What you're describing is not a need to perform operations as another > user, but a need to perform them with DAC_OVERRIDE capability. In Linux, > having uid 0 buys you nothing but access to files owned by uid 0. Sorry, but CAP_DAC_OVERRIDE can, and usually will, be overridden in a typical selinux environment. That is precisely why we had to abandon using it for privileged operations such as binding a socket to a reserved port in the SUNRPC layer in the early 2.6.x days. Josef, if you really need to do this hidden directory creation (which is also something which is not supported by all filesystems, BTW - remember FAT and its 8+3 filenames?) then why not use that as a flag to signal that the directory is visible to unionfs rather than have it signal invisibility? Then leave the whole issue of whether or not to set it to the user. Cheers, Trond