From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: Why does devices cgroup check for CAP_SYS_ADMIN explicitly? Date: Tue, 6 Nov 2012 08:52:46 -0800 Message-ID: <20121106165246.GF30069@mtj.dyndns.org> References: <20121106023845.GI19354@mtj.dyndns.org> <877gpzrlir.fsf@xmission.com> <20121106150131.GA14640@sergelap> <20121106150639.GB30069@mtj.dyndns.org> <871ug6rbio.fsf@xmission.com> <20121106154320.GE30069@mtj.dyndns.org> <87sj8mogpp.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1G2bRJ4fX3Gg2+rkB51NezncvlPQfrYv+cZ0bXa/mVc=; b=PbnbhFep7eK+7hi6m3V23UYKU8Aep6l5/hjjhAhGERmKZiDOXqA9KgoZGF1rRNFSTI IGdjHD2KFm9m4i6woD27motUIDDIyrVqdKHdKNGAL/nyifzcEZlKVnyGORX8uqGzSipv H/ii/Aao2nrMwYIg+jvGqtT0ZizfUh5jPAi08t78aa2IHVpbUEQutWm5jGe4uXoVEGCX cdAmB9BaCmmq9aGyX524AN6T/2049UKOJ+QnMKCDCusdwUKLv+v1hlTa4AuyjI+B9HsJ tty1ofMVlq/LQm75kXYZlWh3IhYDAeSrTKnXY71ARjRfCmkLJ3qf8Nt+48ua8nzoTT59 50MQ== Content-Disposition: inline In-Reply-To: <87sj8mogpp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Aristeu Rozanski , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Hello, Eric. On Tue, Nov 06, 2012 at 08:10:10AM -0800, Eric W. Biederman wrote: > mknod is gated by the vfs with a capability call. > > open does not perform the CAP_MKNOD check. > > Since the device cgroup prevents opening of device nodes adding > permission to access a new device node (update_access) is roughly > equivalent to mknod when the device cgroup does not exist. I think that's a jump. > To preserve the notion that only a privileged user can grant access to > device nodes we need a capability check. Especially since the device > cgroup is designed to limit processes with uid == 0. > > Without a capability check a process with CAP_DAC_OVERRIDE can go > shopping for a device control group that happens to have the device it > wants to use. > > Similary without a capability check a process with CAP_DAD_OVERRIDE can > add or remove any device node into a device control group. > > I don't see how the device control group can limit uid == 0 with the > device control group without making the operations require a capability > you don't give to ever user who has uid == 0. devices cgroup adds to restrictions what a group of tasks can do. Access to cgroup configuration is gated by cgroup core (currently by VFS permissions) and that's it. I really don't want each controller to develop its own permission checks. If a controller can't live with that, it probably shouldn't be a cgroup controller. So, if you think the CAP check is needed for cgroup in general (and can justify it), please feel free to move it to cgroup core; otherwise, the CAP check is going away from devices and if devices can't live with that, it probably shouldn't have been a cgroup controller from the beginning. Thanks. -- tejun