Date: Tue, 16 Feb 2016 13:32:22 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Eric van Gyzen <vangyzen@FreeBSD.org> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160216113222.GY91220@kib.kiev.ua> In-Reply-To: <56C24586.9050906@FreeBSD.org> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote: > My only comment on kern_umtx.c is, why are the permission checks compiled out? Assume that we changed the ABI of libthr and shared locks do not require an offpage. Then, access to the locks is completely controlled by the access to the page containing the lock. If a process can mmap the page, it can own the lock. >From this point of view, access to the offpage shared memory object is the same as the access to the key page. Which is the reason to not include the access permissions checks. On the other hand, if you have something in kernel, which also owns a reference on ucred (for other means), you sure consider whether the usual access control is appropriate. Mostly, I leave the #ifdef-ed checks to reconsider it later, which worked since you asked the question. I definitely do not see much use of the shm_access() checks, but I am not completely sure about possible mac policies utilization there, although I do not really think they could be usefully attached to the app-level locks. > I also reviewed versions 2 and 3; the revisions look fine. Thank you very much.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160216113222.GY91220>