[PATCH app/xauth 1/2] Merge only entries with equal dpy and protoname.
Merging two lists, or adding entry a into list acts unexpectedly if the list
contains FamilyWild or entry with an empty display numbers. For example:
> xauth list
##6f70656e737573652d74756d626c6577656564#: MIT-MAGIC-COOKIE-1
1500d80327733252cc42ba469138a259
> xauth add test/unix:2 MIT-MAGIC-COOKIE-1 aabbccddeeff00112233445566778899
> xauth list
test/unix:2 MIT-MAGIC-COOKIE-1 aabbccddeeff00112233445566778899
This is because merge_entries compares entries using `match_auth`, which
follows the same rules as XauGetBestAuthByAddr. Following these rules is good
when filtering the output of `xauth list`, but for merging we should compare
for equality. It used to be done that way before commit 1555fff4. That commit
changed it to improve the `xauth list` behavior, but did not seem consider the
impact on merge.
---
process.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/process.c b/process.c
index 12a1765..d3ea435 100644
--- a/process.c
+++ b/process.c
@@ -1057,16 +1057,22 @@ extract_entry(const char *inputfilename, int lineno,
Xauth *auth, char *data)
static int
-eq_auth(Xauth *a, Xauth *b)
+eq_auth_dpy_and_name(Xauth *a, Xauth *b)
{
return((a->family == b->family &&
a->address_length == b->address_length &&
a->number_length == b->number_length &&
a->name_length == b->name_length &&
- a->data_length == b->data_length &&
memcmp(a->address, b->address, a->address_length) == 0 &&
memcmp(a->number, b->number, a->number_length) == 0 &&
- memcmp(a->name, b->name, a->name_length) == 0 &&
+ memcmp(a->name, b->name, a->name_length) == 0) ? 1 : 0);
+}
+
+static int
+eq_auth(Xauth *a, Xauth *b)
+{
+return((eq_auth_dpy_and_name(a, b) &&
+ a->data_length == b->data_length &&
memcmp(a->data, b->data, a->data_length) == 0) ? 1 : 0);
}
@@ -1100,17 +1106,6 @@ match_auth_dpy(register Xauth *a, register Xauth *b)
return 1;
}
-/* return non-zero iff display and authorization type are the same */
-
-static int
-match_auth(register Xauth *a, register Xauth *b)
-{
-return ((match_auth_dpy(a, b)
-&& a->name_length == b->name_length
-&& memcmp(a->name, b->name, a->name_length) == 0) ? 1 : 0);
-}
-
-
static int
merge_entries(AuthList **firstp, AuthList *second, int *nnewp, int *nreplp)
{
@@ -1144,7 +1139,7 @@ merge_entries(AuthList **firstp, AuthList *second, int
*nnewp, int *nreplp)
a = first;
for (;;) {
- if (match_auth (a->auth, b->auth)) { /* found a duplicate */
+ if (eq_auth_dpy_and_name (a->auth, b->auth)) { /* found a
duplicate */
AuthList tmp; /* swap it in for old one */
tmp = *a;
*a = *b;
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH app/xauth 2/2] Sort entries from most specific to most generic.
There is no point in adding entry or merging lists if a FamilyWild entry would
end in front of any entry, or entry without display number would end in front
of entry with number.
This sorts all entries in order:
* FamilyWild without display number
* FamilyWild with display number
* Other family without display number
* Other family with display number
The order of the entries in each category is kept.
---
process.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/process.c b/process.c
index d3ea435..f3d6ca4 100644
--- a/process.c
+++ b/process.c
@@ -1170,6 +1170,45 @@ merge_entries(AuthList **firstp, AuthList *second, int
*nnewp, int *nreplp)
}
+static void
+sort_entries(AuthList **firstp)
+{
+/* Insert sort, in each pass it removes auth records of certain */
+/* cathegory from the given list and inserts them into the sorted list. */
+
+AuthList *sorted = NULL, *sorted_tail = NULL;
+AuthList *prev, *iter, *next;
+
+#define SORT_OUT(EXPRESSION) { \
+ prev = NULL; \
+ for (iter = *firstp; iter; iter = next) { \
+ next = iter->next; \
+ if (EXPRESSION) { \
+ if (prev) \
+ prev->next = next; \
+ else \
+ *firstp = next; \
+ if (sorted_tail == NULL) { \
+ sorted = sorted_tail = iter; \
+ } else { \
+ sorted_tail->next = iter; \
+ sorted_tail = iter; \
+ } \
+ iter->next = NULL; \
+ } else { \
+ prev = iter; \
+ } \
+ } \
+}
+
+SORT_OUT(iter->auth->family != FamilyWild && iter->auth->number_length !=
0);
+SORT_OUT(iter->auth->family != FamilyWild && iter->auth->number_length ==
0);
+SORT_OUT(iter->auth->family == FamilyWild && iter->auth->number_length !=
0);
+SORT_OUT(iter->auth->family == FamilyWild && iter->auth->number_length ==
0);
+
+*firstp = sorted;
+}
+
static Xauth *
copyAuth(Xauth *auth)
{
@@ -1508,6 +1547,7 @@ do_merge(const char *inputfilename, int lineno, int argc,
const char **argv)
printf ("%d entries read in: %d new, %d replacement%s\n",
nentries, nnew, nrepl, nrepl != 1 ? "s" : "");
if (nentries > 0) xauth_modified = True;
+ sort_entries(&xauth_head);
}
return 0;
@@ -1656,6 +1696,7 @@ do_add(const char *inputfilename, int lineno, int argc,
const char **argv)
fprintf (stderr, "unable to merge in added record\n");
return 1;
}
+sort_entries(&xauth_head);
xauth_modified = True;
return 0;
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH app/xauth 0/2] Fix xauth interaction with wildcard entries.
These patches attempt to fix how 'xauth add' and 'xauth merge' interacts with FamilyWild entries and entries with no display number. Ultimately it is attempt to fix this downstream bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1083869 The problem in that bug is that GDM creates Xauthority file that contains FamilyWild entry with no display number. This matches everything. That works as long as the Xauthority file is used for only one X server. But if user uses the vncserver script, it tries to add additional record using the xauth command. This record gets "merged" with the wildcard record and replaces it. Since wildcard entries and entries with no display numbers are valid (see email "Is xauth entry without display number valid?" on x...@lists.x.org), lets fix how the merge works and sort the entries from most specific to most generic. Michal Srb (2): Merge only entries with equal dpy and protoname. Sort entries from most specific to most generic. process.c | 66 --- 1 file changed, 51 insertions(+), 15 deletions(-) -- 2.13.6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/3] xwayland: Add hook to check wl interface for glamor
Hi Lyude, On Wed, May 30, 2018 at 9:31 PM, Lyude Paul wrote: > NAK. I'm starting to see the problems with this approach I originally hit now. > > So: there's some unexpected catches when it comes to EGL client extensions. On > a system using glvnd with the nvidia driver, the EGL client extension list > will have /both/ the client extensions for the nvidia EGL driver and the > client extensions for the Mesa driver. An example from my test machine: > > EGL client extensions string: > EGL_EXT_platform_base EGL_EXT_device_base # ← nvidia! > EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions > EGL_KHR_debug EGL_EXT_platform_x11 EGL_EXT_platform_device > EGL_EXT_platform_wayland EGL_MESA_platform_gbm # ← mesa! > EGL_MESA_platform_surfaceless > > This is fine, but what it means is that we're going to have to take the > presence of either of these extensions as a sign that their respective EGL > backends -might- be there. e.g. we can't try to make a choice on avoiding > trying EGLStreams simply because GBM might be there, which is currently what > this patch does: > > * During init, xwl_glamor_should_use_gbm() tells us we should prefer GBM over >EGLStreams > * We select the gbm egl backend's hook for checking for the wl interfaces > * In xwl_screen_init(), we check for wl_drm and don't see it > * xwl_glamor_has_wl_interface() returns FALSE, which makes us disable glamor >and fall back to software rendering I see... Problem is that we need to check for the interfaces and can do so only once we're connected to the Wayland display, after we called xwl_glamor_init_gbm() or xwl_glamor_init_eglstream() which setup the init_wl_registry() handler to read the wl_registry advertised by the compositor, and this is part of either xwl_gbm_private or xwl_eglstream_private structures which get allocated once we've selected the backend... So this is a chicken and egg situation here. So those interfaces for all backends, wl_drm, wl_eglstream_display, wl_eglstream_controller, and init_wl_registry() need to be moved out of the egl_backend, so that we can read *all* the available Wayland interfaces first and then decide which backend to use based on *both* EGL extensions available *and* Wayland interfaces as well. That's a bit of refactoring of the egl_backend code, working on it... [...] Cheers, Olivier ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
