On Wed, Oct 09, 2013 at 06:08:28PM +0200, Sébastien Marie wrote: > On Wed, Oct 09, 2013 at 05:57:13PM +0200, Giovanni Bechis wrote: > > On 10/09/13 17:54, Matthieu Herrb wrote: > > > On Wed, Oct 09, 2013 at 04:47:41PM +0200, Giovanni Bechis wrote: > > >> On 10/09/13 16:32, Stuart Henderson wrote: > > >>> On 2013/10/09 16:03, Sébastien Marie wrote: > > >>>> Hi, > > >>>> > > >>>> I just upgrade my ports to -current (dmesg below), but I have problems > > >>>> with qt4 applications. > > >>>> > > >>>> For example, starting qtconfig4 (which is packaged in qt4-4.8.5) result > > >>>> of X11 error: > > >>> > > >>> Confirmed (and on amd64 here, so it's not just a problem with a > > >>> particular > > >>> pkg snap). > > >>> > > >> With this snapshot and inteldrm is working fine: > > >> OpenBSD 5.4-current (GENERIC.MP) #65: Thu Oct 3 18:48:14 MDT 2013 > > > > > > How are you starting X (xdm, gdm, startx, ... ? ) > > > > > I am using xdm(1). > > me too. >
THis is a known issue with the Xshm and X privilege separation. If the application is too paranoid and creates its shared memory segments (with shmget(2)) with a mode of 700 (in shmflags), then the privilege reduced X server won't be able to access it. Ihmo the reasonable solution is to put users allowed to use X in the _x11 group and create the shared memory segements with group _x11 and mode 770. Or just be laxist and create them 777. 10 years ago, I've looked at implementing the shm access through the privileged monitor of the X server but it seemed a bad idea, and it still seems to be the case nowadays. And upstreeam X developpers say that Xshm should be dropped completly, that the Unix socket local transport should be fast enough. Or maybe DRI could be used. But of course this doesn't produce a fix for $SUBJECT. -- Matthieu Herrb
