On Tue, Jun 26, 2018 at 12:36 AM Paul Moore <p...@paul-moore.com> wrote: > > On Mon, Jun 25, 2018 at 12:34 PM Jann Horn <ja...@google.com> wrote: > > If a user is accessing a file in selinuxfs with a pointer to a userspace > > buffer that is backed by e.g. a userfaultfd, the userspace access can > > stall indefinitely, which can block fsi->mutex if it is held. > > > > For sel_read_policy(), remove the locking, since this method doesn't seem > > to access anything that requires locking. > > Forgive me, I'm thinking about this quickly so I could be very wrong > here, but isn't the mutex needed to prevent problems in multi-threaded > apps hitting the same fd at the same time?
sel_read_policy() operates on a read-only copy of the policy, accessed via ->private_data, allocated using vmalloc in sel_open_policy() via security_read_policy(). As far as I can tell, nothing can write to that read-only copy of the policy. None of the handlers in sel_policy_ops write - they just mmap as readonly (in which case you're already reading without locks, by the way) or read. _______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
