On Mon, Jun 25, 2018 at 6:40 PM Jann Horn <ja...@google.com> wrote: > > 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.
Great, thanks. -- paul moore www.paul-moore.com _______________________________________________ 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.
