From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Whitcroft Subject: Can the VFS layer rely on i_uid Date: Mon, 5 Mar 2012 12:12:39 +0000 Message-ID: <20120305121239.GB9978@shadowen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kees Cook To: linux-fsdevel@vger.kernel.org Return-path: Received: from youngberry.canonical.com ([91.189.89.112]:36011 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756561Ab2CEMMm (ORCPT ); Mon, 5 Mar 2012 07:12:42 -0500 Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: We have been testing with some of the newly proposed security checks from the Yama security module. Some of the pending checks for that module use inode ownership and permissions as factors in these checks, checks essentially done at the VFS level. The issue I am seeing is that not all filesystems populate i_uid or i_mode (completely). Overlayfs for example does not populate i_uid in its inodes. This leads these Yama checks to fail unexpectedly. When an inode does not provide a permissions() op generic permissions checks are used and these assume that i_mode, i_uid, and i_gid are all populated, using them directly to perform these checks. When a permissions() op is provided obviously this code is not used. What is not so clear to me is whether there is still an assumption or requirement that these are populated in this case. My gut feeling is that if you have a permissions() op then there is no obligation to use these fields at all, indeed it seems entirely reasonable that your permission model not map sensibly onto such permissions. I am hoping that someone in the know could clarify what you may rely on when at the VFS layer, or point me at the documenation if I have missed it. Thanks. -apw