Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbaBDP6A (ORCPT ); Tue, 4 Feb 2014 10:58:00 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:41825 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753440AbaBDP54 (ORCPT ); Tue, 4 Feb 2014 10:57:56 -0500 Date: Tue, 4 Feb 2014 07:57:44 -0800 From: Christoph Hellwig To: Steven Whitehouse Cc: Al Viro , Linus Torvalds , Christoph Hellwig , Ilya Dryomov , Sage Weil , Dave Jones , Linux Kernel Mailing List , ceph-devel@vger.kernel.org, linux-fsdevel , Guangliang Zhao , Li Wang , zheng.z.yan@intel.com Subject: Re: [PATCH v2] ceph: fix posix ACL hooks Message-ID: <20140204155744.GA3974@infradead.org> References: <1391013467-7598-1-git-send-email-ilya.dryomov@inktank.com> <20140130075421.GA10050@infradead.org> <20140203102943.GF11829@infradead.org> <20140203215908.GD10323@ZenIV.linux.org.uk> <20140203224034.GF10323@ZenIV.linux.org.uk> <1391513615.2766.18.camel@menhir> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391513615.2766.18.camel@menhir> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 04, 2014 at 11:33:35AM +0000, Steven Whitehouse wrote: > To diverge from that topic for a moment, this thread has also brought > together some discussion on another issue which I've been pondering > recently.... that of whether the inode operations for get/set_xattr > should take a dentry or not. I had thought that we'd come to the > conclusion that 9p made it impossible to swap the current dentry > argument for an inode, and I was about to send a patch for selinux > support on clustered fs on that basis. However the discussion in this > thread has made me wonder whether that really is the case or not.... Al, > can you confirm whether your xattr-experimental patches are still under > active consideration? My plan was to work on the 9p and cifs conversions using the d_find_alias hack we have in ceph right now. That means the base work could switch to passed in dentries or in case of 9p the per-inode fids easily. > The other question that I have relating to that side of things, is why > security_inode_permission() is called from __inode_permission() rather > than from generic_permission() ? Maybe there is a good reason, but I > can't immediately see what it is at the moment. Seems like almost everything of the security_* family is called from the VFS instead of the filesystem. There's also some very odd other behaviour in there, e.g. for the xattrs sets are handed to the filesystem first, and then the xattr layer calls into the security layer, which for reads the filesystems is never reached at all. > In response to the question elsewhere about GFS2 calling > gfs2_permission() after the vfs has already done its checks, that is > indeed down to needing to ensure that we have the cluster locks when > this check is called. More importantly to know that things haven't > changed since the VFS called the same function in case we've raced with > another node changing the permissions, for example. There are a number > of cases where we redo vfs level checks for this reason, Seems like we should be able to grab a cluster lock where we grab i_mutex in the namespace code to avoid having to redo all these checks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/