On Sat Jul 22, 2023 at 07:51:15AM +0200, Matthieu Herrb wrote:
> On Thu, Jul 20, 2023 at 08:32:30PM +0200, Rafael Sadowski wrote:
> > On Thu Jul 20, 2023 at 04:31:55PM +0100, Stuart Henderson wrote:
> > > On 2023/07/20 17:27, Rafael Sadowski wrote:
> > > > Let's start with a quote from an old try:
> > > >
> > > > "Our Xorg server doesn't run under the same uid as the client, the
> > > > client
> > > > needs to create the shared memory area with mode 0666.
> > > >
> > > > We are doing the same in misc/screen-shm. Of course, the consequence
> > > > here would be to do it for all Qt applications."
> > > >
> > > > -- https://marc.info/?l=openbsd-ports&m=167110468109188&w=2
> > > >
> > > > There was a veto from sthen@, which was perfectly okay and right. For
> > > > error analysis and to exclude that this function is not used, I need the
> > > > shm mode from time to time. I would like to solve it with an environment
> > > > variable (QT_OPENBSD_SHM_MODE).
> > >
> > > From that mail,
> > >
> > > "What are the consequences of leaving this as-is? (i.e. what's broken
> > > now that changing this would fix?)"
> > >
> >
> > Nothing is broken and nothing is would fix for now. It just helps me to
> > debug Qt application or large ecosystem like KDE plasma. When I increase
> > the debug level I see that shm could not be init and therefore I can not
> > exclude that exactly this is a problem.
> >
> > Long story short: It helps me not to always have to build Qt myself.
> >
>
> Are there still places in the Qt library that don't use
> xcb_shm_attach_fd() to attach shared memory segments to the X server ?
No, it looks like they are using this pattern:
It starts here:
286 if (!QXcbBackingStore::createSystemVShmSegment(m_xcbConnection)) {
287 qCDebug(lcQpaXcb, "failed to create System V shared memory
segment (remote "
288 "X11 connection?), disabling SHM");
289 m_hasShm = m_hasShmFd = false;
290 }
409 bool QXcbBackingStoreImage::createSystemVShmSegment(xcb_connection_t *c,
size_t segmen
410
xcb_shm_segment_info_t *shmInfo)
411 {
412 const int id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0600);
413 if (id == -1) {
414 qCWarning(lcQpaXcb, "shmget() failed (%d: %s) for size %zu",
errno, strerror(e
415 return false;
416 }
417
418 void *addr = shmat(id, nullptr, 0);
419 if (addr == (void *)-1) {
420 qCWarning(lcQpaXcb, "shmat() failed (%d: %s) for id %d", errno,
strerror(errno
421 return false;
422 }
423
424 if (shmctl(id, IPC_RMID, nullptr) == -1)
425 qCWarning(lcQpaXcb, "Error while marking the shared memory
segment to be destr
426
427 const auto seg = xcb_generate_id(c);
428 auto cookie = xcb_shm_attach_checked(c, seg, id, false);
429 auto *error = xcb_request_check(c, cookie);
430 if (error) {
431 qCWarning(lcQpaXcb(), "xcb_shm_attach() failed");
Or in sort:
412 const int id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0600);
425 const auto seg = xcb_generate_id(c);
426 auto cookie = xcb_shm_attach_checked(c, seg, id, false);
427 auto *error = xcb_request_check(c, cookie);
431 qCWarning(lcQpaXcb(), "xcb_shm_attach() failed");
https://github.com/qt/qtbase/blob/5.15/src/plugins/platforms/xcb/qxcbbackingstore.cpp#L424
There is no different path for Linux/FreeBSD here.
>
> This was introduced more than 10 years ago, so that if the X server is
> not running as root it can still access shared memory segments created
> by the clients, possibly running as a different uid as the server, and
> preserving the privacy of the shm contents.
>
> In that case 600 is perfectly fine and applications don't need to
> fallback on non-shm based transports.
>
> If Qt is using xcb_shm_attach() or XShmAttach() is that only on
> OpenBSD because it thinks OpenBSD doesn't have xcb_shm_attach_fd(),i
> ot is it the same on Linux ? (since Linux is not running X as root
> anymore either whith systemd, they would face the same issues as you).
$ dolphin # OpenBSD with ports qtbase
qt.scaling: Apply QT_SCALE_FACTOR 1
qt.qpa.xcb: Has MIT-SHM : true
qt.qpa.xcb: Has MIT-SHM FD : true
qt.qpa.xcb: xcb_shm_attach() failed
qt.qpa.xcb: failed to create System V shared memory segment (remote X11
connection?), disabling SHM
qt.qpa.xcb: Using XInput version 2.2
$ dolphin # Linux Debian sid
qt.qpa.xcb: Has MIT-SHM : true
qt.qpa.xcb: Has MIT-SHM FD : true
qt.qpa.xcb: Using XInput version 2.2
>
> PS: I remember we once noticed that mesa was also not using
> xcb_shm_attach_fd() on OpenBSD. I should have a look to confirm this,
> but I'm not available for the next 2 weeks to do that, sorry.
> --
> Matthieu Herrb
>
