From mboxrd@z Thu Jan 1 00:00:00 1970 From: sds@tycho.nsa.gov (Stephen Smalley) Date: Mon, 30 Oct 2017 13:03:47 -0400 Subject: [PATCH V3 1/2] security: Add a cred_getsecid hook In-Reply-To: References: <20171026084055.25482-1-mjg59@google.com> <1509027658.25604.4.camel@tycho.nsa.gov> Message-ID: <1509383027.10174.5.camel@tycho.nsa.gov> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Mon, 2017-10-30 at 10:57 +0000, Matthew Garrett via Selinux wrote: > On Thu, Oct 26, 2017 at 3:20 PM, Stephen Smalley > wrote: > > On Thu, 2017-10-26 at 01:40 -0700, Matthew Garrett via Selinux > > wrote: > > > +static void selinux_cred_getsecid(const struct cred *c, u32 > > > *secid) > > > +{ > > > +?????rcu_read_lock(); > > > +?????*secid = cred_sid(c); > > > +?????rcu_read_unlock(); > > > > Is rcu_read_lock() necessary here? Seems like we use cred_sid() in > > many > > places without it. > > Ah, I thought it was based on task_sid(), but I guess that's actually > protecting the __task_cred()? It appears to me that in all other cases, we are either dealing with the current cred, or something in the call chain of cred_sid() is holding a reference to the cred, or something in the call chain of cred_sid() has called rcu_read_lock() already. I might have missed something though, and I don't know how safe it is to assume that all future callers will do this. cc'd David for his thoughts. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html