From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 04/13] security/selinux: check for LOOKUP_RCU in _follow_link. Date: Fri, 20 Mar 2015 05:12:24 +0000 Message-ID: <20150320051224.GV29656@ZenIV.linux.org.uk> References: <20150316043602.23648.52734.stgit@notabene.brown> <20150316044319.23648.82820.stgit@notabene.brown> <20150316210035.GC29656@ZenIV.linux.org.uk> <20150320153930.1f180e06@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: NeilBrown Return-path: Content-Disposition: inline In-Reply-To: <20150320153930.1f180e06@notabene.brown> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Mar 20, 2015 at 03:39:30PM +1100, NeilBrown wrote: > rcu_read_unlock(); > security_compute_av(ssid, tsid, tclass, avd); > rcu_read_lock(); > > (yes: unlock, and then lock). > > so avc_has_perm_noaudit needs to bail out of RCU-walk if node turns out to be > NULL. NFI, but since a) the guts of security_compute_av() are under rwlock (shared), I rather doubt that it could e.g. block b) avc_has_perm_noaudit() is called from selinux_inode_permission(), which is called inside RCU-walk - it's hit on selinux setups in every successful inode_permission() I'd say that it's no worse than it already was. AFAICS, it's a slowpath and we don't want to hold rcu_read_lock() over it to avoid stalls, but if the caller of avc_has_perm_noaudit() used to want rcu_read_lock(), well, we'll just risks stalls