AW: [Xlib] Ignoring BadAccess errors

[Walter Harms]

since no one feels the need to answer is will try:

Having those exceptions is obviously a hack to allow clients
to continue on "minor" errors. e.g. BadAccess can be generated
by xgrab*() and may work in a second attempt. 

NTL this should be documented in the doc.

regarding you original question:
 I need a function which robustly returns an
error when we in untrusted context, which returned exactly when client is untrusted and not for any other reasons.

this is something i can not answer, sorry.

re,
 wh
________________________________________
Von: xorg-devel <xorg-devel-bounces at lists.x.org> im Auftrag von Nekun <nekokun at firemail.cc>
Gesendet: Dienstag, 20. April 2021 13:19
An: xorg-devel at lists.x.org
Betreff: [Xlib] Ignoring BadAccess errors

WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht auf Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die Absender*in und wissen, dass der Inhalt sicher ist.


Hi all.

Can somebody explain me why BadAlloc and BadAccess errors are ignored in
Xlib reply processing, but only in certain conditions? As I can see
(maybe I misunderstood something, please correct), in _Xreply:
https://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xcb_io.c#n655 ,
after sending a request, at first we process pending responses in input
buffer and handle it without any exceptions and then we process the last
response and ignore some errors: BadName and BadFont in some conditions
described in the Xlib spec:
https://www.x.org/releases/current/doc/libX11/libX11/libX11.html#Using_the_Default_Error_Handlers
, and, suddenly, completely ignore BadAccess and BadAlloc. I don't found
any references for that behavior. In result, I can't trap these errors
with my error handler if an Xlib request wrapper calls _Xreply
explicitly. Some wrappers, such as XBell, writes a request to output
queue, calls the sync handler and then errors are handled without
exception because XSync adds InputSetFocus to queue, so the target
request is processed with no-exception logic described above. This issue
arised when I worked on fixing the broken untrusted context check in GTK
(GDK) at display opening. I need a function which robustly returns an
error when we in untrusted context, which returned exactly when client
is untrusted and not for any other reasons, and throw in the gdk_x_error
trap. Tried XListHosts and failed for reasons described above. Maybe I
can use a return value of some function instead of error handling? Seems
like X11 security extension more often returns fake values for untrusted
clients rather than errors, but not sure that is possible to distinguish
between a fake value and a real in any response. Stucked here.
_______________________________________________
xorg-devel at lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel