Date: Tue, 16 Feb 2016 08:56:32 -0600 From: Eric van Gyzen <vangyzen@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <56C338A0.2060205@FreeBSD.org> In-Reply-To: <20160216113222.GY91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/16/2016 05:32, Konstantin Belousov wrote: > 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. This makes sense. > 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. This sounds wise. I'll keep it in mind. > 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 would tend to agree, but I haven't used MAC for several years, so I'm not sure either. Cheers, Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56C338A0.2060205>