dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2022-11-21T15:11:13Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/195libdbus client should try "AUTH EXTERNAL\r\n" first?2022-11-21T15:11:13ZBugzilla Migration Userlibdbus client should try "AUTH EXTERNAL\r\n" first?## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104589)](https://bugs.freedesktop.org/show_bug.cgi?id=104589)**
## Description
While documenting how the EXTERNAL auth mechanism works (on ...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104589)](https://bugs.freedesktop.org/show_bug.cgi?id=104589)**
## Description
While documenting how the EXTERNAL auth mechanism works (on Bug #104224), I found out that dbus-daemon has in fact always supported the empty string as an authorization identity. This means "I am whoever the kernel says I am", which is the behaviour we actually want.
This is clearly superior to what all practical D-Bus clients currently do, which is to send getuid() or geteuid(), so something like "I am uid 1000, please ask the kernel for confirmation". In particular, if the client is in a non-init uid namespace on Linux, then the uid it gets from geteuid() might not match what the dbus-daemon in the init namespace thinks its effective uid is.
One complication is that this will break interoperability with D-Bus server implementations whose authors didn't know this was meant to work (notably GDBus).https://gitlab.freedesktop.org/dbus/dbus/-/issues/194Document best practices for usernames in <policy>2018-10-15T13:31:33ZBugzilla Migration UserDocument best practices for usernames in <policy>## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104586)](https://bugs.freedesktop.org/show_bug.cgi?id=104586)**
## Description
Because some NSS mechanisms require network access, and some...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104586)](https://bugs.freedesktop.org/show_bug.cgi?id=104586)**
## Description
Because some NSS mechanisms require network access, and some network access mechanisms like NetworkManager require D-Bus, usernames in the `<policy>` for the dbus-daemon must be resolvable during boot prior to network access becoming available. In practice, this means they must be local (for example nss_files, nss_db, or even nss_systemd's special cases for the root and nobody users).
(In reply to Tom Gundersen on Bug #104224)
> As such, no dbus-based NSS resolution is possible. This is ok
> because we assume any user/group names used in the configuration files are
> given statically in /etc/passwd and friends, rather than resolved over
> something like LDAP (local policy referencing remote users sounds very
> strange). This is not at all obvious, and it is probably something we should
> document better. I'd even propose to add this to the spec if we all agreed.
dbus-daemon's XML configuration language is not (currently) in the scope of the spec, but I'd welcome patches to dbus-daemon(1) that said this.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/193Add build information for Android platforms2018-10-16T13:19:17ZBugzilla Migration UserAdd build information for Android platforms## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104022)](https://bugs.freedesktop.org/show_bug.cgi?id=104022)**
## Description
DBus for android is required to build several KD...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104022)](https://bugs.freedesktop.org/show_bug.cgi?id=104022)**
## Description
DBus for android is required to build several KDE Frameworks package
on KDE CI system (see
https://phabricator.kde.org/R857:da6f5208d5e087870af2b3d0eeb83941fca500d2
for a list) and there are no related build information.https://gitlab.freedesktop.org/dbus/dbus/-/issues/192Do something about test/data/*-messages/*.message2018-10-15T13:39:44ZBugzilla Migration UserDo something about test/data/*-messages/*.message## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103758)](https://bugs.freedesktop.org/show_bug.cgi?id=103758)**
## Description
dbus-message-builder was a domain-specific language for buil...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103758)](https://bugs.freedesktop.org/show_bug.cgi?id=103758)**
## Description
dbus-message-builder was a domain-specific language for building D-Bus message blobs. It was introduced in 2003, and deleted in early 2005 when the type system was rewritten to be fully recursive. (See https://bugs.freedesktop.org/show_bug.cgi?id=103601#c28 for VCS archaeology)
These tests have been diagnosed as "skipped" since the commit that also deleted dbus-message-builder.[ch]:
commit 9d21554dd3b560952cd5aa607c4ec07898c0b260
Author: Havoc Pennington <hp@redhat.com>
Date: 2005-01-23 06:10:07 +0000
2005-01-23 Havoc Pennington <hp@redhat.com>
* dbus/dbus-message-factory.c, dbus/dbus-message-util.c:
get this all working, not many tests in the framework yet though
but even before that, the message builder language was disabled by:
+ if (FALSE) /* Message builder disabled, probably permanently,
+ * I want to do it another way
which was part of this mega-commit:
commit 9c3d566e95c9080f6040c64531b0ccae22bd5d74
Author: Havoc Pennington <hp@redhat.com>
Date: 2005-01-15 07:15:38 +0000
2005-01-15 Havoc Pennington <hp@redhat.com>
* Land the new message args API and type system.
This patch is huge [...]
As a result of the type system having changed, the specific content of these files is probably no longer useful. However, the general concept of loading message blobs with known content and asserting that they do something sensible is potentially a valuable one, so maybe we should rescue some test coverage from them?
If we want a DSL for writing messages, here is a straw-man:
message in xxd format, with comment lines introduced by #
(xxd format is: "%08x: " offset, followed by up to 32 columns of hex
with a space after each group of 4 digits, optionally followed by a
double space and an ignored text-dump of the content)
VALID or INVALID
if VALID, some sort of encoding of the intended message content
(GVariant text serialization?)
if INVALID, the error code we expect to see
Unfortunately it would not really be OK for the "embedded tests" to link GLib for the GVariant text syntax. However, we could do something like this:
* in embedded tests
* load each valid message (optionally with the crazy OOM-simulation),
assert success or OOM
* load each invalid message, assert the expected error code
* in GLib'y modular tests
* load each valid message, assert expected content
I am not going to have time to work on this any time soon, but I'd review patches.
Until this happens, it might make sense to drop the unused code and data files, leaving this bug open - they haven't actually been used since 2005, and it would be trivial to get them back from git history for inspiration.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/191sysdeps-win: _dbus_get_autolaunch_address prints to stdout/stderr2020-04-27T12:16:49ZBugzilla Migration Usersysdeps-win: _dbus_get_autolaunch_address prints to stdout/stderr## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103756)](https://bugs.freedesktop.org/show_bug.cgi?id=103756)**
## Description
The coding convention for the dbus library is to report erro...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103756)](https://bugs.freedesktop.org/show_bug.cgi?id=103756)**
## Description
The coding convention for the dbus library is to report errors through a DBusError (analogous to a GError or a C++ exception) so that they can be caught and handled by application code in whatever way is most appropriate for the application. In particular, this avoids corrupting stdout/stderr if the application is using them for something machine-readable.
However, the Windows implementation of _dbus_get_autolaunch_address() doesn't do that consistently:
if (!SearchPathA(dbus_module_path, daemon_name, NULL, sizeof(dbus_exe_path), dbus_exe_path, &lpFile))
{
dbus_set_error_const (error, DBUS_ERROR_FAILED, "could not find dbus-daemon executable");
retval = FALSE;
fprintf (stderr, "please add the path to %s to your PATH environment variable\n", daemon_name);
fprintf (stderr, "or start the daemon manually\n\n");
}
(This is after Bug #103601 - before that, it used printf to stdout, which was worse, because stdout is more likely to be used for machine-readable output.)
The warnings that are currently printed to stderr should probably move into the message part of the DBusError. It's OK for a DBusError to be reasonably long.
In library code, we should only emit warnings to stderr as a last resort when nothing else is possible (and if we do that, we should use _dbus_warn() instead of fprintf).
I'm not intending to fix this myself, since I don't develop on Windows and so can't meaningfully test this.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/190Containers (#100344): Let monitors match messages to/from a container2018-10-15T13:40:12ZBugzilla Migration UserContainers (#100344): Let monitors match messages to/from a container## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103470)](https://bugs.freedesktop.org/show_bug.cgi?id=103470)**
## Description
Flatpak has "flatpak run --log-system-bus --log-session-bus", i...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103470)](https://bugs.freedesktop.org/show_bug.cgi?id=103470)**
## Description
Flatpak has "flatpak run --log-system-bus --log-session-bus", implemented by passing arguments to the flatpak-dbus-proxy.
To get rid of the flatpak-dbus-proxy, we should achieve feature parity with it; so there should be some arguments that Flatpak can pass to dbus-monitor that will make it log traffic to/from a container.
dbus-monitor uses the Monitoring interface, which uses match rules, so we will need a match rule with container=/org/freedesktop/DBus/Containers1/c47, or a pair of rules with sender_container=/org/freedesktop/DBus/Containers1/c47 and destination_container=/org/freedesktop/DBus/Containers1/c47.
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)https://gitlab.freedesktop.org/dbus/dbus/-/issues/189Containers (#171): Work out what to do about unrestricted connections2023-10-27T18:59:05ZBugzilla Migration UserContainers (#171): Work out what to do about unrestricted connectionsOriginally [fdo#103458](https://bugs.freedesktop.org/show_bug.cgi?id=103458), older comments will be more readable there.
## User story
dbus maintainers want a plan for how Flatpak is going to represent unrestricted connections and whe...Originally [fdo#103458](https://bugs.freedesktop.org/show_bug.cgi?id=103458), older comments will be more readable there.
## User story
dbus maintainers want a plan for how Flatpak is going to represent unrestricted connections and whether they are going to have any restrictions at the D-Bus level, so that we can avoid painting ourselves into a corner.
## Description
Flatpak has the concept of unrestricted connections to the session and system buses, selected by --socket=session-bus, --socket=system-bus. These bind-mount the session or system bus socket directly into the container if possible (or use xdg-dbus-proxy in pass-through mode if the socket is abstract), without interposing `xdg-dbus-proxy --filter` and its implicit restrictions on what the connection can do (such as forbidding `UpdateActivationEnvironment()`).
These connections are effectively totally trusted - there are lots of ways an unrestricted connection to the session bus can execute arbitrary code outside the sandbox context (doing the equivalent of `systemd-run --scope $your_payload_here` is an obvious one, and so is the o.fd.Flatpak.Development interface), and the same is probably true for the system bus. But we probably want to be able to *identify* these connections, even though we can't *control* them.
With the implementation in [fdo#101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354), there are some hard-coded things that such connections can never do:
* Call methods with `METHOD_FLAG_PRIVILEGED`:
`DBus.UpdateActivationEnvironment()`
(privilege escalation via LD_PRELOAD etc.),
`DBus.BecomeMonitor()` (privileged information leak)
* Call methods with `METHOD_FLAG_NO_CONTAINERS`:
`Containers1.AddServer()` (privilege escalation via specifying weaker access
control, identity spoofing by specifying a different identity for the
server)
`Containers1.{StopInstance,StopListening}()` (denial of service),
the whole `Verbose` interface (indirect information leak, denial of service
because Verbose is really really spammy),
the whole `Stats` interface (minor information leak)
* Add match rules that enable eavesdropping (privileged information leak)
* Report that systemd activation has failed (denial of service)
* Probably more in future
I'm not sure whether a contained app will ever do these in practice. I could imagine GNOME Builder wanting to `BecomeMonitor()` or use Verbose or Stats, although at the moment it just uses `--talk-name=org.freedesktop.Flatpak` to escalate its privileges, rather than having a totally unrestricted socket.
Options include:
1. Deny some or all of this on filtered connections (#185), let
container managers allow it by adding extra allow rules, and maybe
allow it on unfiltered connections (until #185, that's all
connections) to preserve the invariant that not specifying filtering
means allowing everything that can possibly be allowed;
but that would mean that #185 would become part of the minimum viable
product for #171, which is undesirable, because #185 will never
be finished unless someone else helps.
2. Unconditionally forbid this stuff on the assumption that nobody will
ever need it
(This is @smcv's plan if there are no strong objections.)
3. Either now, or later (if we unconditionally forbade it but we turned
out to be wrong about never needing it), have a flag in the `a{sv}` of
named arguments that relaxes our access control for a particular
container instance (maybe `{'AllowMonitoring': <true>}` etc.?), and
relax some of the restrictions in that situation.
(This is @smcv's fallback plan if 2. turns out to have been wrong.)
If we might let containers do privileged things in future, we might want to change the semantics of `M_F_PRIVILEGED` so that it's orthogonal to `M_F_NO_CONTAINERS` (in [fdo#101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354), `M_F_NO_CONTAINERS` was strictly weaker than `M_F_PRIVILEGED`); or, alternatively, we might want to add a `M_F_PRIVILEGED_UID` that is really orthogonal to `M_F_NO_CONTAINERS`, which would make `M_F_PRIVILEGED` equivalent to `M_F_PRIVILEGED_UID|M_F_NO_CONTAINERS`.
## Deadline
If there is no objection to this by the end of September 2023, when Containers is otherwise ready for merge, @smcv plans to go with option 2 and close this with no further action. We can still take option 3 later, if we need it.https://gitlab.freedesktop.org/dbus/dbus/-/issues/188Containers (#171): consider adding an option to let other uids in2023-09-06T17:15:44ZBugzilla Migration UserContainers (#171): consider adding an option to let other uids in## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103457)](https://bugs.freedesktop.org/show_bug.cgi?id=103457)**
## Description
::: bus/containers.c
@@ +318,5 @@
> + *
> + * TODO: For the...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#103457)](https://bugs.freedesktop.org/show_bug.cgi?id=103457)**
## Description
::: bus/containers.c
@@ +318,5 @@
> + *
> + * TODO: For the system bus we might want a way to opt-in to allowing
> + * other uids, in which case we would refrain from overwriting the
> + * BusContext's unix_user_function; but that isn't part of the
> + * lowest-common-denominator implementation. */
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
* [Bug 104610](https://bugs.freedesktop.org/show_bug.cgi?id=104610)
### Blocking
* [Bug 100344](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/187dbus-1.13 release for Windows2018-10-15T13:41:00ZBugzilla Migration Userdbus-1.13 release for Windows## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103435)](https://bugs.freedesktop.org/show_bug.cgi?id=103435)**
## Description
This task is intended to track required task for...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#103435)](https://bugs.freedesktop.org/show_bug.cgi?id=103435)**
## Description
This task is intended to track required task for the DBus 1.12 release on Windows.
Currently the following tasks comes into my mind or has been raised by others:
1. Specify minimal supported os version and compiler
2. complete open bugs (for example [bug 99751](https://bugs.freedesktop.org/show_bug.cgi?id=99751))
2. Update website
3. Make binary packages for Windows (packages are currently in preparation at https://build.opensuse.org/project/show/home:rhabacker:branches:windows:mingw:win32:unstable)
4. Find a download location for binary packages e.g. https://dbus.freedesktop.org/releases/win or something else if not possible [1]
5. ....
[1] obs would also be possible in theory by using the following search https://software.opensuse.org/package/mingw32-dbus-1-portable?search_term=mingw32-dbus-1-portable for portable packages or https://software.opensuse.org/package/mingw32-dbus-1-portable?search_term=mingw32-dbus-1-installer for exe installer or specifing a direct link to a package but is currently limited to having 7z files or exe installer inside a rpm container. A fix requires to add a new "raw" repository format to obs which would make it possible to place the native packages into a sub dir of https://download.opensuse.org. If this is not possible or will be too much work, or may be rejected by the obs maintainer a release script is required to unpack the native packages and prepare the release as it has been done for KMyMoney (see https://cgit.kde.org/kmymoney.git/tree/maintainer/release-windows-packages)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/186Containers (#100344): allow container to live longer than container manager2023-11-30T19:09:01ZBugzilla Migration UserContainers (#100344): allow container to live longer than container manager## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101903)](https://bugs.freedesktop.org/show_bug.cgi?id=101903)**
## Description
+++ This bug was initially created as a clone of Bug #100344 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101903)](https://bugs.freedesktop.org/show_bug.cgi?id=101903)**
## Description
+++ This bug was initially created as a clone of Bug #100344 +++
Following on from Bug #101354, we want to let short-lived container manager helper processes create a container with a lifetime and then get out of the way. In particular, Flatpak does not have a "supervisor" process once the sandboxed app is running, except for bwrap (which is minimal, sometimes setuid, and does not use D-Bus) and the flatpak-dbus-proxy (which, long term, we want to remove).
In Bug #101354, the container would stop listening when its creator falls off the bus. This is not suitable for Flatpak long-term.
The design we had at the GTK hackfest was to fd-pass in the read end of a pipe. Until it polls readable, the container server keeps listening. When it polls readable, the container server stops.
This can go in the named parameters a{sv}.
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
### Blocking
* [Bug 100344](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/185Containers (#171): message filtering/policy2023-10-27T19:02:17ZBugzilla Migration UserContainers (#171): message filtering/policy## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101902)](https://bugs.freedesktop.org/show_bug.cgi?id=101902)**
## Description
+++ This bug was initially created as a clone of Bug #100344 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101902)](https://bugs.freedesktop.org/show_bug.cgi?id=101902)**
## Description
+++ This bug was initially created as a clone of Bug #100344 +++
Bug #101354 does not let container managers arrange for messages to be filtered. This is part of the wish-list for Bug #100344, because it would eventually let us get rid of flatpak-dbus-proxy.
Design sketch:
* New named parameter:
Allow: a(usos)
Array of tuples (flags: u, bus name: s, object path: o, interface: s)
If this parameter is given, it sets the messages and operations
that are allowed.
An empty array allows sending method calls to the message
bus, and receiving exactly one reply or error for each method call
successfully sent (unless it was NO_REPLY). It also allows
receiving method calls from connections that are not in a container,
and sending exactly one reply or error for each method call
received (unless it was NO_REPLY). It does not allow receiving
broadcast signals. This is the most restrictive possible policy.
[TODO: Does it allow receiving unicast signals from connections
that are not in a container?]
Each array entry is a /rule/ which allows additional operations
according to its flags. If the bus name is the empty string,
it matches all bus names (and hence all possible connections).
If the interface is the empty string, it matches messages with
any interface or no interface. If the object path is "/" and
the OBJECT_PATH_IS_SUBTREE flag is present, it matches messages
with any object path or no object path.
SEE:
The connection may call GetNameOwner(), NameHasOwner(),
GetConnectionCredentials(), etc. to inspect connections
that are in the queue to own the given bus name.
The object path and interface are ignored when checking
for SEE access.
CALL_METHODS:
The connection may send method call messages to
connections that are in the queue to own the given
bus name. Implies SEE.
RECEIVE_BROADCASTS (or RECEIVE_SIGNALS?):
The connection may receive broadcasts (or all signals?)
from connections that are in the queue to own the given
bus name, if they match the given object path and
interface.
TALK: alias for SEE | CALL_METHODS | RECEIVE_whatever
BUS_NAME_IS_SUBTREE:
The bus name is matched in the same way as arg0namespace
in signal match rules, instead of as an exact match.
OBJECT_PATH_IS_SUBTREE:
In addition to messages that match exactly, the object
path matches messages with an object path that has
additional components. For example, "/foo" matches messages
with object path "/foo" or "/foo/bar" but not "/foolish".
Note that this is not identical to arg0path in signal
match rules.
SEND_UNIX_FDS, RECEIVE_UNIX_FDS:
The connection may send, receive messages that contain
Unix fds and match the given bus name, object path and
interface.
OWN_BUS_NAME:
The connection may use RequestName and ReleaseName
to own the given bus name. Implies SEE and TALK.
The object path must be "/" and the interface must
be "".
Not giving this parameter is equivalent to providing policies
that allow the confined connection to send and receive every
message, own every bus name, etc. This is the least restrictive
possible policy.
* o.fd.Containers.GrantAccess(a(uos): rules)
Rules are as above, but bus name is implicitly the caller's
unique name
* o.fd.Containers.RevokeAccess(a(uos): rules)
Rules are as for GrantAccess. If a rule was added more than
once, each revocation removes one of the identical copies.
Version: git master
### Depends on
* #201
* #202
* #203
* #204
* #205
* #206https://gitlab.freedesktop.org/dbus/dbus/-/issues/184Containers (#100344): fd-passing-based creation2018-10-15T13:41:25ZBugzilla Migration UserContainers (#100344): fd-passing-based creation## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101898)](https://bugs.freedesktop.org/show_bug.cgi?id=101898)**
## Description
+++ This bug was initially created as a clone of Bug #100344 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101898)](https://bugs.freedesktop.org/show_bug.cgi?id=101898)**
## Description
+++ This bug was initially created as a clone of Bug #100344 +++
Following on from Bug #101354, Allison wants to be able to arrange for container instances' servers to appear inside containers in a more elegant way than creating them outside and bind-mounting them in. I already intended to do this, but it is not part of the minimum viable product (Bug #101354).
Design sketch:
The named_parameters a{sv} argument may contain:
ServerSocket: h
A socket (fstat() must indicate format S_IFSOCK)
with SO_DOMAIN = AF_UNIX and SO_TYPE = SOCK_STREAM. The
container manager will arrange for bind() and listen() to be called
on this socket so that it is made available inside the container.
If ServerSocketReadyNotifier is not provided, the container manager
must already have called bind() and listen() (the SO_ACCEPTCONN socket
option is 1 and getsockname() returns an address), such that this
socket is already ready for the message bus to call accept() on it.
In this case the AddServer() method will return the socket's path
and D-Bus address as usual.
If ServerSocketReadyNotifier is provided, then the container manager
may delay calling bind() and listen() until just before it makes the
ServerSocketNotifierReadyNotifier poll readable. In this case the
AddServer() method cannot determine the socket's address, so it
will return an empty byte-array instead of the socket's absolute
path, and an empty string instead of its D-Bus address.
ServerSocketReadyNotifier: h
The reading end of a pipe or FIFO (format S_IFIFO). The container
manager will wait for this pipe to poll readable, then close it
and begin to accept() on the ServerSocket.
(The container manager should keep the write end of this socket open
until it has called bind() and listen() on the ServerSocket,
then close the write end, resulting in the read end polling readable.)
Version: git master
### Depends on
* [Bug 101354](https://bugs.freedesktop.org/show_bug.cgi?id=101354)
### Blocking
* [Bug 100344](https://bugs.freedesktop.org/show_bug.cgi?id=100344)https://gitlab.freedesktop.org/dbus/dbus/-/issues/183Passed FDs are incorrectly assigned to messages2018-10-12T21:31:27ZBugzilla Migration UserPassed FDs are incorrectly assigned to messages## Submitted by David Herrmann `@dvdhrm`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101755)](https://bugs.freedesktop.org/show_bug.cgi?id=101755)**
## Description
Hi
The dbus specification states:
`UNIX_FDS: The...## Submitted by David Herrmann `@dvdhrm`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101755)](https://bugs.freedesktop.org/show_bug.cgi?id=101755)**
## Description
Hi
The dbus specification states:
`UNIX_FDS: The number of Unix file descriptors that accompany the message. If omitted, it is assumed that no Unix file descriptors accompany the message. The actual file descriptors need to be transferred via platform specific mechanism out-of-band. They must be sent at the same time as part of the message itself. They may not be sent before the first byte of the message itself is transferred or after the last byte of the message itself.`
The spec clearly states that FDs must be sent together with the actual bytes of the message they belong to. However, dbus-daemon does not verify that behavior.
In particular, if you send a message with 1 FD, but UNIX_FDS set to 0, followed by a message with 0 FDs, but UNIX_FDS set to 1, then dbus-daemon will attribute that FD to the second message.
It is not clear whether dbus-daemon behaves incorrectly here. The spec only defines how *senders* are supposed to work. However, it is very unfortunate that dbus-daemon does not verify that behavior. In particular, either the behavior of dbus-daemon is wanted, in which case the spec is needlessly restricted, or the definition of the spec is what is wanted, then dbus-daemon needs to be fixed.
IOW: Right now, the spec treats the stream of bytes and FDs to be the same stream. But dbus-daemon treats both as two independent streams, where the byte-stream controls when to pop-off elements from the FD stream.
It would be nice if we can clear this up.
Thanks
David
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/182SASL pipelining discards FDs2018-10-12T21:31:24ZBugzilla Migration UserSASL pipelining discards FDs## Submitted by David Herrmann `@dvdhrm`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101754)](https://bugs.freedesktop.org/show_bug.cgi?id=101754)**
## Description
Hi
We use pipelining for SASL exchanges from clie...## Submitted by David Herrmann `@dvdhrm`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101754)](https://bugs.freedesktop.org/show_bug.cgi?id=101754)**
## Description
Hi
We use pipelining for SASL exchanges from clients. Meaning, we send all the SASL commands concatenated without waiting for responses from the server. Moreover, we don't block on SASL at all, so any Hello() or other D-Bus message can be pipelined as well.
This turned out to work pretty well and fast. It improves responsiveness for short-lived applications considerably, since no connection-roundtrip is needed, but everything can be dispatched with a single sendmmsg(2) call.
However, as it turns out, dbus-daemon does not correctly attribute FDs to their respective bytes. If we send the SASL commands, followed by a D-Bus Message with UNIX_FDS>0, dbus-daemon considers those FDs part of the SASL exchange and disconnects the client.
The expected behavior would be for dbus-daemon to dispatch FDs only together with the skbuff that transmitted the FDs.
sd-bus suffers from the same issue, and I filed a report there as well:
https://github.com/systemd/systemd/pull/5520
It contains a test-case that shows the problematic behavior. Same test applies to libdbus1.
Thanks
David
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/181Consider dropping support for /var/run/console (--with-console-auth-dir)2022-05-20T12:08:31ZBugzilla Migration UserConsider dropping support for /var/run/console (--with-console-auth-dir)## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101629)](https://bugs.freedesktop.org/show_bug.cgi?id=101629)**
## Description
dbus-daemon implements the deprecated at_console feature (see a...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101629)](https://bugs.freedesktop.org/show_bug.cgi?id=101629)**
## Description
dbus-daemon implements the deprecated at_console feature (see also Bug #39611) with several mechanisms. One of them is to stat the "tag file" /var/run/console/${username}, and if it exists, that is assumed to signify that ${username} is at the console. Those are the semantics that were implemented by pam_console and pam_foreground, both of which were later superseded by ConsoleKit, which was in turn superseded by systemd-logind (or occasionally ConsoleKit2) on Linux systems.
According to Bug #14053, some distributions patch ConsoleKit to create those tag files, but normally it does not. Judging by Bug #94591, ConsoleKit2 doesn't either.
For completeness, the other mechanisms we have for at_console are:
* for Linux with systemd or systemd-shim: check whether they are logged-in
on any seat using systemd-logind APIs
* for Solaris: there is a file that will be owned by the active console user
(assumed to be unique!)
I think we should consider removing the "tag files" handling.
Version: git master
### Depends on
* [Bug 101964](https://bugs.freedesktop.org/show_bug.cgi?id=101964)https://gitlab.freedesktop.org/dbus/dbus/-/issues/180Consider defining system bus socket to be in /run/dbus on FHS systems2023-01-19T15:38:23ZBugzilla Migration UserConsider defining system bus socket to be in /run/dbus on FHS systems[Originally fd.o #101628](https://bugs.freedesktop.org/show_bug.cgi?id=101628).
The interoperable location of the system bus socket in system-wide installations of D-Bus on Unix systems is /var/run/dbus/system_bus_socket.
Recent Linux ...[Originally fd.o #101628](https://bugs.freedesktop.org/show_bug.cgi?id=101628).
The interoperable location of the system bus socket in system-wide installations of D-Bus on Unix systems is /var/run/dbus/system_bus_socket.
Recent Linux distributions implement /run, which is standardized by the FHS version 3.0. /run is intended to be transient (a tmpfs) and is the best place to put system-wide sockets like the one for the system bus.
In ~~all /run implementations that I am aware of~~ most /run implementations, but notably not Slackware, /run is in fact guaranteed to be equivalent to /var/run, typically by making /var/run a symbolic link to /run (a symbolic link in the other direction would also be a valid implementation, and so would a Linux bind-mount or FreeBSD nilfs). However, the FHS does not actually guarantee this. (I think it should, and I have opened <https://bugs.linuxfoundation.org/show_bug.cgi?id=1396>).
At the moment, our policy is that the interoperable location is officially /var/run, and if /var/run and /run somehow differ, /var/run is the right one to use. However, this can cause problems if access to /var is mediated by an automounter.
We have considered changing the D-Bus Specification to have /run/dbus/system_bus_socket as the preferred/canonical path, and correspondingly changing the implementation to use ${runstatedir}/dbus/system_bus_socket.
However, we cannot just say "yes, *obviously* we should do this", use `${runstatedir}`, and move on with our lives, because there exist operating systems (Slackware) where `/var/run` and `/run` both exist, *and they are different*. On those operating systems, changing the well-known system bus socket would be a backwards compatibility break.
I think the policy applied by those operating systems is foolish - they are why we can't have nice things - but we take backwards compatibility seriously.
For dbus to use `/run` in preference to `/var/run` while working correctly in all cases, we would have to make clients try to connect to both addresses, and make the server try to listen on both addresses (but cope gracefully with inability to listen in `/var/run` if it's already listening in `/run`).
This is complicated by the fact that the system bus socket is a configure-time parameter, and is not necessarily in either `/var/run` or `/run` - it might be in `/opt/freedesktop/dbus/var/run` or something.
If you know for sure that *on your specific operating system*, `/var/run` is guaranteed to be equivalent to `/run` and the latter is the path you want, then you can configure `--with-system-socket=/run/dbus/system_bus_socket`.https://gitlab.freedesktop.org/dbus/dbus/-/issues/179Add message ordering guarantees to the D-Bus specification2024-03-15T12:40:58ZBugzilla Migration UserAdd message ordering guarantees to the D-Bus specification## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101563)](https://bugs.freedesktop.org/show_bug.cgi?id=101563)**
## Description
The specification doesn’t actually state what ordering guar...## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101563)](https://bugs.freedesktop.org/show_bug.cgi?id=101563)**
## Description
The specification doesn’t actually state what ordering guarantees it provides about messages. Currently, dbus-daemon guarantees that all peers will see messages from connection C in the order that they were received by the daemon from peer C (if they are to see those messages at all). (This phrasing might be wrong and needs clarification.)
Given that plenty of bits of software depend on those ordering guarantees, and that we would consider any message bus implementation which *doesn’t* provide them to be wrong, it’s probably appropriate to add them to the spec.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/178It would be nice if dbus-send also accepted "--user"2018-10-15T14:30:24ZBugzilla Migration UserIt would be nice if dbus-send also accepted "--user"## Submitted by Danny Milosavljevic
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101375)](https://bugs.freedesktop.org/show_bug.cgi?id=101375)**
## Description
Created attachment 131848
dbus-send: Add "--user"
**...## Submitted by Danny Milosavljevic
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101375)](https://bugs.freedesktop.org/show_bug.cgi?id=101375)**
## Description
Created attachment 131848
dbus-send: Add "--user"
**Patch 131848**, "dbus-send: Add "--user"":
[dbus-send-user-bus.patch](/uploads/1c0b79719e29aa41783f9a978c7e159f/dbus-send-user-bus.patch)
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/177[SELinux] Return the context of the dbus-daemon process if asking about org.f...2018-10-15T14:49:37ZBugzilla Migration User[SELinux] Return the context of the dbus-daemon process if asking about org.freedesktop.DBus## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101315)](https://bugs.freedesktop.org/show_bug.cgi?id=101315)**
## Description
Hi,
Currently when asked the SELinux context of the own...## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101315)](https://bugs.freedesktop.org/show_bug.cgi?id=101315)**
## Description
Hi,
Currently when asked the SELinux context of the owner of org.freedesktop.DBus, the dbus-daemon is returning an error.
In the same situation when asked about the Unix user or the PID, the daemon would return its own user or pid.
The following patch is doing the same for the SELinux context by returning the daemon one
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/176fdpass test fails on Solaris2018-10-15T14:35:00ZBugzilla Migration Userfdpass test fails on Solaris## Submitted by vlm..@..lny.cz
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101221)](https://bugs.freedesktop.org/show_bug.cgi?id=101221)**
## Description
Created attachment 131553
Increase the number of file descri...## Submitted by vlm..@..lny.cz
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101221)](https://bugs.freedesktop.org/show_bug.cgi?id=101221)**
## Description
Created attachment 131553
Increase the number of file descriptors
Hi,
The test fdpass expects to have more than ~800 file descriptors available for current process. On Solaris the default is to have the soft limit set to 256 file descriptors.
The test fails with this error:
Not enough RLIMIT_NOFILE to run this test
This is the attached patch I am using on Solaris. It could be enanced (like #ifdef __sun), but I am not sure whether something like this would be accepted. I'm not sure whether increasing the file descriptors limit too high does not make some of the tests to not work as they won't reach the limit at 1024.
~~**Patch 131553**~~, "Increase the number of file descriptors":
[dbus-06-test-fdpass.patch](/uploads/c08b368a895a7d5d93ba213da421bdc5/dbus-06-test-fdpass.patch)
Version: 1.10