Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: Start an Xvfb server in our CI tests #951

Merged
merged 1 commit into from
Oct 14, 2024
Merged

ci: Start an Xvfb server in our CI tests #951

merged 1 commit into from
Oct 14, 2024

Conversation

apyrgio
Copy link
Contributor

@apyrgio apyrgio commented Oct 14, 2024

Remove the installation steps for Xvfb, since it's already included in GitHub actions, and fire up an Xvfb server with disabled host-based access control.

Initially, we tried to wrap our CI tests with xvfb-run, but any X11 client within our Podman container failed with the following error message:

Authorization required, but no authorization protocol specified.

This error message is usually thrown when the X11 client does not provide the magic cookie in the Xauthority file back to the X11 server. In our case though, we can verify that commands in our Podman container read the Xauthority file successfully:

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X99"}, 21) = -1 ECONNREFUSED (Connection refused)
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X99"}, 110) = 0
getpeername(3, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X99"}, [124->21]) = 0
uname({sysname="Linux", nodename="dangerzone-dev", ...}) = 0
access("/home/runner/work/dangerzone/dangerzone/cookie", R_OK) = 0
openat(AT_FDCWD, "/home/runner/work/dangerzone/dangerzone/cookie", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=59, ...}) = 0
read(4, "\1\0\0\rfv-az1915-957\0\299\0\22MIT-MAGIC"..., 4096) = 59
read(4, "", 4096)                       = 0
close(4)                                = 0
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="l\0\v\0\0\0\0\0\0\0\0\0", iov_len=12}, {iov_base="", iov_len=0}], 2) = 12
recvfrom(3, 0x55a5635c0050, 8, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\0@\v\0\0\0\20\0", 8, 0, NULL, NULL) = 8
recvfrom(3, "Authorization required, but no a"..., 64, 0, NULL, NULL) = 64
write(2, "Authorization required, but no a"..., 64Authorization required, but no authorization protocol specified
) = 64

The line with the magic cookie is:

read(4, "\1\0\0\rfv-az1915-957\0\299\0\22MIT-MAGIC"..., 4096) = 59

Since we are not sure why we are not allowed access to the X11 server from the Podman container, we decided to disable host-based access controls altogether. This is not a security concern, since this X11 session is a remote one. However, we shouldn't run tests this way in dev machines.

Fixes #949

Remove the installation steps for Xvfb, since it's already included in
GitHub actions, and fire up an Xvfb server with disabled host-based
access control.

Initially, we tried to wrap our CI tests with `xvfb-run`, but any
X11 client within our Podman container failed with the following error
message:

    Authorization required, but no authorization protocol specified.

This error message is usually thrown when the X11 client does not
provide the magic cookie in the Xauthority file back to the X11 server.
In our case though, we can verify that commands in our Podman container
read the Xauthority file successfully:

    socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
    connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X99"}, 21) = -1 ECONNREFUSED (Connection refused)
    close(3)                                = 0
    socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
    getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
    connect(3, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X99"}, 110) = 0
    getpeername(3, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X99"}, [124->21]) = 0
    uname({sysname="Linux", nodename="dangerzone-dev", ...}) = 0
    access("/home/runner/work/dangerzone/dangerzone/cookie", R_OK) = 0
    openat(AT_FDCWD, "/home/runner/work/dangerzone/dangerzone/cookie", O_RDONLY) = 4
    fstat(4, {st_mode=S_IFREG|0600, st_size=59, ...}) = 0
    read(4, "\1\0\0\rfv-az1915-957\0\299\0\22MIT-MAGIC"..., 4096) = 59
    read(4, "", 4096)                       = 0
    close(4)                                = 0
    fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
    fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
    fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
    poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
    writev(3, [{iov_base="l\0\v\0\0\0\0\0\0\0\0\0", iov_len=12}, {iov_base="", iov_len=0}], 2) = 12
    recvfrom(3, 0x55a5635c0050, 8, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
    poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
    recvfrom(3, "\0@\v\0\0\0\20\0", 8, 0, NULL, NULL) = 8
    recvfrom(3, "Authorization required, but no a"..., 64, 0, NULL, NULL) = 64
    write(2, "Authorization required, but no a"..., 64Authorization required, but no authorization protocol specified
    ) = 64

The line with the magic cookie is:

    read(4, "\1\0\0\rfv-az1915-957\0\299\0\22MIT-MAGIC"..., 4096) = 59

Since we are not sure why we are not allowed access to the X11 server
from the Podman container, we decided to disable host-based access
controls altogether. This is not a security concern, since this X11
session is a remote one. However, we shouldn't run tests this way in dev
machines.

Fixes #949
@almet
Copy link
Contributor

almet commented Oct 14, 2024

Thanks for digging and fixing this Alex! Let's consider this solved 👍

It's still a mystery why this stopped working out of the blue though 🤔

@apyrgio apyrgio merged commit fd5aafd into main Oct 14, 2024
76 checks passed
@apyrgio apyrgio deleted the 949-xvfb branch October 14, 2024 14:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Installing xvfb currently breaks our CI tests
2 participants