From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752979AbbCJS51 (ORCPT ); Tue, 10 Mar 2015 14:57:27 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:34106 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751402AbbCJS5X (ORCPT ); Tue, 10 Mar 2015 14:57:23 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150310171133.23081.49616.stgit@buzz> <20150310172206.23081.95005.stgit@buzz> From: Andy Lutomirski Date: Tue, 10 Mar 2015 11:57:01 -0700 Message-ID: Subject: Re: [PATCH RFC v2 2/6] fs: protected project id To: Konstantin Khlebnikov Cc: Konstantin Khlebnikov , Linux FS Devel , Dave Chinner , Jan Kara , "linux-ext4@vger.kernel.org" , "Theodore Ts'o" , Dmitry Monakhov , "linux-kernel@vger.kernel.org" , Li Xi 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 Tue, Mar 10, 2015 at 11:51 AM, Konstantin Khlebnikov wrote: > On Tue, Mar 10, 2015 at 8:32 PM, Andy Lutomirski wrote: >> On Tue, Mar 10, 2015 at 10:22 AM, Konstantin Khlebnikov >> wrote: >>> Historically XFS project id doesn't have any permission control: file owner >>> is able to set any project id. Later they was sealed with user-namespace: >>> XFS allows to change it only from init user-ns. That works fine for isolated >>> containers or if user doesn't have direct access to the filesystem (NFS/FTP). >>> >>> This patch adds sysctl fs.protected_projects which makes changing project id >>> privileged operation which requires CAP_SYS_RESOURCE in current user-namespace. >>> Thus there are two levels of protection: project id mapping in user-ns defines >>> set of permitted projects and capability protects operations within this set. >> >> If I understand this right, this doesn't work. If I lack >> CAP_SYS_RESOURCE but I have two projids mapped, then I can create a >> new userns, map both projids, and get CAP_SYS_RESOURCE. > > Setting project id mapping for nested user-namespace also requires > this capability in parent namespace. The same as for setting uid/gid > mapping but without special case for mapping current uid/gid because > task has no "current" project id. > > This is mentioned in cover letter but I forget it here. Sorry. Right, sorry. I'm still used to projid mappings being unprotected. --Andy > >> >> --Andy >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Andy Lutomirski AMA Capital Management, LLC