Bug 101566 - Add a way to listen on an arbitrary unix:path socket
Summary: Add a way to listen on an arbitrary unix:path socket
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: git master
Hardware: Other All
: medium enhancement
Assignee: Simon McVittie
QA Contact: D-Bus Maintainers
URL: https://github.com/smcv/dbus/commits/...
Whiteboard: review+
Keywords: patch
Depends on:
Blocks: 101354
  Show dependency treegraph
 
Reported: 2017-06-23 16:07 UTC by Simon McVittie
Modified: 2017-06-29 15:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Add unix:dir=/something addresses (8.16 KB, patch)
2017-06-23 16:07 UTC, Simon McVittie
Details | Splinter Review
test/loopback: Don't leak address strings (1.66 KB, patch)
2017-06-28 18:05 UTC, Simon McVittie
Details | Splinter Review
test/loopback: Assert that the connectable address makes sense (3.78 KB, patch)
2017-06-28 18:05 UTC, Simon McVittie
Details | Splinter Review
test/loopback: Exercise unix:dir addresses (1.78 KB, patch)
2017-06-28 18:05 UTC, Simon McVittie
Details | Splinter Review

Description Simon McVittie 2017-06-23 16:07:15 UTC
We now have a way to listen on a fixed socket in XDG_RUNTIME_DIR (unix:runtime=yes creates $XDG_RUNTIME_DIR/bus for the user/session bus, Bug #61303), but on Linux we still do not have a way to force use of path= (as opposed to abstract=) sockets. This would be good for two reasons:

* If a Linux container manager wants to expose a path-based socket
  into the container, it can do so by bind-mounting it in the
  container's filesystem namespace. That cannot work for abstract
  sockets because they are not files.
    
* Conversely, if a Linux container manager does not want to expose
  a path-based socket in the container, it can avoid bind-mounting it,
  or bind-mount some harmless object like /dev/null over it.
  That cannot work for abstract sockets because access to abstract
  sockets is part of the network namespace, which is all-or-nothing.

I'll use this in Bug #101354.

My implementation of Bug #101354 uses something like "unix:dir=/run/user/1000/containers" (substituting and escaping the value of XDG_RUNTIME_DIR at runtime, /run/user/1000 in that example), which is analogous to tmpdir= but without the possibility of using an abstract socket. Other possible syntaxes include:

* unix:type=path,tmpdir=/run/user/1000/containers

* unix:runtime=unique (and abandon the use of a subdirectory)

* unix:generate-path=/run/user/1000/containers

* unix:generate-path=xdg-run/containers (using xdg-run as a special token distinguished from real paths by not being absolute, like in Flatpak)

* unix:generate-path=XDG_RUNTIME_DIR/containers (similar)
Comment 1 Simon McVittie 2017-06-23 16:07:58 UTC
Created attachment 132158 [details] [review]
Add unix:dir=/something addresses

These are like unix:tmpdir=/something, except that the resulting
socket is always path-based, never abstract.

This is desirable for two reasons:

* If a Linux container manager wants to expose a path-based socket
  into the container, it can do so by bind-mounting it in the
  container's filesystem namespace. That cannot work for abstract
  sockets because they are not files.

* Conversely, if a Linux container manager does not want to expose
  a path-based socket in the container, it can avoid bind-mounting it,
  or bind-mount some harmless object like /dev/null over it.
  That cannot work for abstract sockets because access to abstract
  sockets is part of the network namespace, which is all-or-nothing.
Comment 2 Philip Withnall 2017-06-27 18:44:20 UTC
Comment on attachment 132158 [details] [review]
Add unix:dir=/something addresses

Review of attachment 132158 [details] [review]:
-----------------------------------------------------------------

r+, although a test in test/loopback.c would be nice. Could be done as a follow-up commit.
Comment 3 Simon McVittie 2017-06-28 18:04:29 UTC
(In reply to Philip Withnall from comment #2)
> r+, although a test in test/loopback.c would be nice.

Good idea. It turns out that test also leaks address strings.
Comment 4 Simon McVittie 2017-06-28 18:05:02 UTC
Created attachment 132304 [details] [review]
test/loopback: Don't leak address strings

dbus_server_get_address() returns a copy. It isn't clear why.
Comment 5 Simon McVittie 2017-06-28 18:05:20 UTC
Created attachment 132305 [details] [review]
test/loopback: Assert that the connectable address makes  sense

When we listen on a tcp: address we should get a connectable tcp:
address, and so on.
Comment 6 Simon McVittie 2017-06-28 18:05:34 UTC
Created attachment 132306 [details] [review]
test/loopback: Exercise unix:dir addresses
Comment 7 Philip Withnall 2017-06-29 10:36:49 UTC
Comment on attachment 132304 [details] [review]
test/loopback: Don't leak address strings

Review of attachment 132304 [details] [review]:
-----------------------------------------------------------------

r+
Comment 8 Philip Withnall 2017-06-29 10:38:43 UTC
Comment on attachment 132305 [details] [review]
test/loopback: Assert that the connectable address makes  sense

Review of attachment 132305 [details] [review]:
-----------------------------------------------------------------

r+
Comment 9 Philip Withnall 2017-06-29 10:44:20 UTC
Comment on attachment 132306 [details] [review]
test/loopback: Exercise unix:dir addresses

Review of attachment 132306 [details] [review]:
-----------------------------------------------------------------

r+
Comment 10 Simon McVittie 2017-06-29 15:25:03 UTC
Thanks, merged for 1.11.14.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.