Support sdbus clients #54

mardy · 2024-03-25T09:39:38Z

This is built on top of #26. I've kept the original commit by @refi64 and added one to address the issue raised during the review.

Whether my commit actually succeeds in addressing that problem is something I'm not sure of, since I couldn't actually reproduce the original issue. But from my first tests it appears that sdbus clients can connect and send methods calls.

Possible fix for #21

bilelmoussaoui

various code style comments

flatpak-proxy.c

sophie-h · 2024-05-07T12:41:41Z

I cannot confirm that the patch fixes the issue for me.

mardy · 2024-05-08T06:47:42Z

I cannot confirm that the patch fixes the issue for me.

Hi Sophie, can you please tell me how to reproduce the issue?

bilelmoussaoui · 2024-05-08T11:07:39Z

I cannot confirm that the patch fixes the issue for me.

Hi Sophie, can you please tell me how to reproduce the issue?

You can use this flatpak https://github.com/zecakeh/zbus-flatpak-portal, you might have to run cargo update.

sophie-h · 2024-05-08T11:54:04Z

You can use this flatpak https://github.com/zecakeh/zbus-flatpak-portal

If you just use cargo run outside a Flatpak it should run properly. Afterwards, you can run it from a flatpak by

flatpak run --filesystem=host --command=./target/debug/zbus-flatpak-portal app.drey.Warp

Where you can use any id of an installed app instead of app.drey.Warp.

This then gives

Creating connection…
thread 'main' panicked at src/main.rs:7:60:
called `Result::unwrap()` on an `Err` value: InputOutput(Custom { kind: BrokenPipe, error: "failed to read from socket" })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

(Sorry if this is all obvious for you. Just wanted to make sure you can reproduce it.)

bilelmoussaoui · 2024-05-09T15:27:23Z

You can use this flatpak https://github.com/zecakeh/zbus-flatpak-portal

If you just use cargo run outside a Flatpak it should run properly. Afterwards, you can run it from a flatpak by
flatpak run --filesystem=host --command=./target/debug/zbus-flatpak-portal app.drey.Warp
Where you can use any id of an installed app instead of app.drey.Warp.

This then gives
Creating connection…
thread 'main' panicked at src/main.rs:7:60:
called `Result::unwrap()` on an `Err` value: InputOutput(Custom { kind: BrokenPipe, error: "failed to read from socket" })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
(Sorry if this is all obvious for you. Just wanted to make sure you can reproduce it.)

Note that zbus 4.2.1 includes a hack to workaround this issue, so you would have to make sure it is using zbus 4.2.0

mardy · 2024-05-16T12:56:44Z

Thanks for your help! I added one more commit (I guess it can be squashed with the previous ones, but for now I'll keep it separate as the commit message sheds some light on it). Now I can run the zbus-flatpak-portal program.

I added one more member (sent) to the Buffer structure. It may be possible to do without it, but the code was hard to understand because the pos and size members were being used with a different meaning depending on whether we were reading from or writing to the buffer; and the fact that we pass buffers from one socket to the other increases on this confusion.

I didn't want to make a too invasive change, but if you agree I'd rename the members like this (suggestions welcome!):

size -> capacity ("size" can also be OK, if you insist :-) )
pos -> "length", "used", "data_size"?
sent -> keep as is?

sophie-h

The latest version does seem to fix the problems for me!

@mardy could you maybe address the small review comments that are open such that we can hopefully move forward with this soon? :)

sophie-h · 2024-06-22T12:54:09Z

flatpak-proxy.c

+                {
+                  /* Immediately send the outgoing buffer */
+                  GSocketConnection *connection = client->bus_side.connection;
+                  GSocket *socket = g_socket_connection_get_socket (connection);


This line does not compile for me

../flatpak-proxy.c: In function ‘side_in_cb’: ../flatpak-proxy.c:3029:28: error: declaration of ‘socket’ shadows a parameter [-Werror=shadow] 3029 | GSocket *socket = g_socket_connection_get_socket (connection); | ^~~~~~ ../flatpak-proxy.c:2959:22: note: shadowed declaration is here 2959 | side_in_cb (GSocket *socket, GIOCondition condition, gpointer user_data) | ~~~~~~~~~^~~~~~ cc1: some warnings being treated as errors

sophie-h · 2024-06-22T12:58:42Z

I didn't want to make a too invasive change, but if you agree I'd rename the members like this (suggestions welcome!):

size -> capacity ("size" can also be OK, if you insist :-) )

pos -> "length", "used", "data_size"?

sent -> keep as is?

Maintainers have been very open to making the code clearer. However, maybe you can add these changes as an additional commit to simplify the review?

swick · 2024-06-24T14:53:14Z

flatpak-proxy.c

              if (found_auth_end)
-                client->authenticated = TRUE;
+                client->auth_state = client->auth_server_backlog
+                  ? AUTH_WAITING_FOR_BACKLOG
+                  : AUTH_COMPLETE;


Could use some braces.

And maybe be more explicit: client->auth_server_backlog > 0

Mmm... This is the original commit from @refi64, which I based my work on. I included in the branch as-is and then I added my fixes on top of his.

I don't think I should change this commit. Maybe then it's better if I merge his and my commit (and I will fix all these remarks), and then I just credit him in the commit message? WDYT?

swick · 2024-06-24T15:07:18Z

flatpak-proxy.c

+                    {
+                      line_start = line_end + strlen (AUTH_LINE_SENTINEL);
+
+                      if (--client->auth_server_backlog == 0)


Not a fan of side effects in if statements.

swick · 2024-06-24T15:09:18Z

flatpak-proxy.c

+              if (client->auth_server_backlog == 0)
+                client->auth_state = AUTH_COMPLETE;


Moving this to the end of the if above makes it easier to follow.

swick · 2024-06-24T15:13:02Z

This contains commits which are broken by themselves. Can you please squash thing properly so that each commit is working?

swick · 2024-06-24T15:18:55Z

flatpak-proxy.c

@@ -298,6 +298,7 @@ struct FlatpakProxyClient
  AuthState     auth_state;


I don't understand what this commit changes. What is being fixed up exactly?

mardy · 2024-06-25T05:28:05Z

This contains commits which are broken by themselves. Can you please squash thing properly so that each commit is working?

By "broken" you mean "not building" or "not fixing the problem"? If it's the former, then I guess the problem is the warning/error mentioned by Sophie (which I will fix); if the latter, then I guess I should just squash all commits into one, because only the last commit fixes the issue for good.

sd-bus sends the BEGIN command in at the same time as the AUTH command, assuming that the authentication will succeed. This ends up confusing xdg-dbus-proxy, as it assumes that BEGIN is not sent at the same time as any other messages. As a result, the server's authentication replies end up interpreted as standard D-Bus messages, failing parsing and resulting in the client being unable to connect. This changes the code to keep track of the number of authentication commands pipelined with BEGIN, then counts the responses from the server to know when the authentication phase of the connection has actually completed. Fixes flatpak#21 (finally!) Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>

This is a fixup for the previous commit. Signed-off-by: Alberto Mardegan <a.mardegan@omp.ru>

Until the authentication is completed, hold off all client messages received after BEGIN. We only send to the server the authentication commands up (and including) the BEGIN command, but everything past the line terminators is queued into the `extra_input_data` buffer and we stop reading from the client socket. Once the authentication is completed, the (partial) message we saved into `extra_input_data` is queued for the D-Bus server into the first outgoing buffer, and reading from the client socket resumes. Note that in order to cleanly process the partial sendind of data, another offset is introduced into the Buffer structure, which holds the bytes of buffers which have already been sent over the socket. Signed-off-by: Alberto Mardegan <a.mardegan@omp.ru>

bilelmoussaoui reviewed May 7, 2024

View reviewed changes

flatpak-proxy.c Outdated Show resolved Hide resolved

flatpak-proxy.c Outdated Show resolved Hide resolved

flatpak-proxy.c Outdated Show resolved Hide resolved

mardy force-pushed the sdbus-auth branch from 5064e57 to 0e63504 Compare May 8, 2024 06:31

sophie-h suggested changes Jun 22, 2024

View reviewed changes

swick reviewed Jun 24, 2024

View reviewed changes

refi64 and others added 3 commits June 25, 2024 08:41

Complete auth only when all bus replies have been received

78d86ae

This is a fixup for the previous commit. Signed-off-by: Alberto Mardegan <a.mardegan@omp.ru>

mardy force-pushed the sdbus-auth branch from 02db72e to 48855d1 Compare June 25, 2024 05:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support sdbus clients #54

Support sdbus clients #54

mardy commented Mar 25, 2024 •

edited

Loading

bilelmoussaoui left a comment

sophie-h commented May 7, 2024

mardy commented May 8, 2024 •

edited

Loading

bilelmoussaoui commented May 8, 2024

sophie-h commented May 8, 2024

bilelmoussaoui commented May 9, 2024

mardy commented May 16, 2024 •

edited

Loading

sophie-h left a comment

sophie-h Jun 22, 2024

mardy Jun 25, 2024

sophie-h commented Jun 22, 2024 •

edited

Loading

swick Jun 24, 2024

swick Jun 24, 2024

mardy Jun 25, 2024

swick Jun 24, 2024

swick Jun 24, 2024

swick commented Jun 24, 2024

swick Jun 24, 2024

mardy commented Jun 25, 2024

		if (client->auth_server_backlog == 0)
		client->auth_state = AUTH_COMPLETE;

		@@ -298,6 +298,7 @@ struct FlatpakProxyClient
		AuthState auth_state;

Support sdbus clients #54

Are you sure you want to change the base?

Support sdbus clients #54

Conversation

mardy commented Mar 25, 2024 • edited Loading

bilelmoussaoui left a comment

Choose a reason for hiding this comment

sophie-h commented May 7, 2024

mardy commented May 8, 2024 • edited Loading

bilelmoussaoui commented May 8, 2024

sophie-h commented May 8, 2024

bilelmoussaoui commented May 9, 2024

mardy commented May 16, 2024 • edited Loading

sophie-h left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sophie-h commented Jun 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swick commented Jun 24, 2024

Choose a reason for hiding this comment

mardy commented Jun 25, 2024

mardy commented Mar 25, 2024 •

edited

Loading

mardy commented May 8, 2024 •

edited

Loading

mardy commented May 16, 2024 •

edited

Loading

sophie-h commented Jun 22, 2024 •

edited

Loading