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/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/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/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.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/175failed RemoveMatch sends error after return (protocol violation)2018-10-15T14:51:02ZBugzilla Migration Userfailed RemoveMatch sends error after return (protocol violation)## Submitted by Matthijs van Duin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101161)](https://bugs.freedesktop.org/show_bug.cgi?id=101161)**
## Description
When RemoveMatch fails, it sends a org.freedesktop.DBus.E...## Submitted by Matthijs van Duin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#101161)](https://bugs.freedesktop.org/show_bug.cgi?id=101161)**
## Description
When RemoveMatch fails, it sends a org.freedesktop.DBus.Error.MatchRuleNotFound error after first sending a normal method return. As a result, clients are unable to determine that RemoveMatch failed.
Example:
~$ dbus-send --dest=org.freedesktop.DBus --print-reply / org.freedesktop.DBus.RemoveMatch string:""
method return time=1495590462.736592 sender=org.freedesktop.DBus -> destination=:1.255 serial=3 reply_serial=2
Monitoring the bus while performing the above reveals that an error reply is also sent, but the client of course discards it.
dbus 1.10.18 and 1.11.12 tested
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/173libdbus calls malloc() after fork(), causing clients to deadlock2020-09-21T19:56:11ZBugzilla Migration Userlibdbus calls malloc() after fork(), causing clients to deadlock## Submitted by Primiano Tucci
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100843)](https://bugs.freedesktop.org/show_bug.cgi?id=100843)**
## Description
TL;DR
dbus-autolaunch causes random hangs, if the hosting pr...## Submitted by Primiano Tucci
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100843)](https://bugs.freedesktop.org/show_bug.cgi?id=100843)**
## Description
TL;DR
dbus-autolaunch causes random hangs, if the hosting process uses an allocator which doesn't have multithreads+fork protections.
This is because a malloc() happens after fork() in _dbus_close_all() via opendir().
Related chromium bugs:
https://crbug.com/695643
https://crbug.com/715658
We had a number of bug reports in chromium where chrome just hangs during startup on Linux.
I narrowed down the cause to libdbus.
The scenario is the following:
- somebody starts chrome in a session that doesn't have a dbus running. This is very common in test harness that run via xvfb. doing that triggers dbus-autolaunch.
- The following happens in the caller process (chrome, in our case):
_dbus_transport_open()
_dbus_transport_open_autolaunch()
_dbus_transport_new_for_autolaunch()
_dbus_get_autolaunch_address()
_read_subprocess_line_argv()
fork()
wait() (on the pipe)
- While in the child process:
fork()
_dbus_close_all()
opendir("/proc/self/fd")
malloc()
Calling malloc in a fork()ed process is bad: if the allocator has no atfork handler, doing that will cause random hangs. More details in crbug.com/695643 .
All this seems to come from an optimization in _dbus_close_all() for Linux [1]. You folks seem to have already a fallback there that is doing a:
maxfds = sysconf (_SC_OPEN_MAX);
for (i = 3; i < maxfds; i++)
close (i);
Which is good and harmless.
The problem instead is when you opendir(/proc/self/fd). Sadly opendir() implies a malloc.
Doing a fork()+malloc() is just asking for troubles. Given that libdbus is a library and not an hemertic executable, IMHO it isn't sensible to expect that hosting process has an allocator with a post-fork handler which handles this corner case.
Can you just always use the fallback and get rid of that /proc/self/fd optimization ? Or achieve that with some other way that doesn't involve a malloc after fork?
For the chrome specific bug we'll be looking into disabling dbus autolunch and reducing our dependencies to that, but in general this feels to me could impact and surprise quite lot of other dbus users (fun fact, the root bug in chrome was caused by somebody calling gconf_client_get_bool).
Regards,
Primiano
[1] https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c?id=d42d167cc3ba0d20aa891a75aa1cd80ec5f490f1#n4368
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/172Specify the drivers error code in the dbus specification2018-11-07T16:57:10ZBugzilla Migration UserSpecify the drivers error code in the dbus specification## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100795)](https://bugs.freedesktop.org/show_bug.cgi?id=100795)**
## Description
Created attachment 131047
document all driver call...## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#100795)](https://bugs.freedesktop.org/show_bug.cgi?id=100795)**
## Description
Created attachment 131047
document all driver calls in the same section
These patches document some well-known error codes returned by the dbus daemon in response to calls to the driver. Error codes returned as a result of internal errors or a misconfigured daemon are not documented.
~~**Patch 131047**~~, "document all driver calls in the same section":
[0001-docs-document-all-of-the-org.freedesktop.DBus-method.patch](/uploads/29d1aa3b0d07bfb1bd18a2929803662d/0001-docs-document-all-of-the-org.freedesktop.DBus-method.patch)https://gitlab.freedesktop.org/dbus/dbus/-/issues/171Containers1: Add restricted, identifiable bus servers for use in containers2023-09-07T21:31:55ZBugzilla Migration UserContainers1: Add restricted, identifiable bus servers for use in containersThis issue is a metabug for the general concept of the Containers interface.
Older comments have been copied from Bugzilla by an automated process, and are likely to be more readable on the [original bug (#100344)](https://bugs.freedesk...This issue is a metabug for the general concept of the Containers interface.
Older comments have been copied from Bugzilla by an automated process, and are likely to be more readable on the [original bug (#100344)](https://bugs.freedesktop.org/show_bug.cgi?id=100344).
## Description
In app-container projects like Flatpak, Snap, Firejail and AppImage, there's a need for a confined/contained/sandboxed app to be able to reach services on the normal session and system buses. However, unrestricted access to those buses is scary (and in particular, the session bus is not considered to be a security boundary, so various services there have APIs that are arbitrary code execution).
The motivating use cases right now are:
* Portals: Portal authors need to be able to identify whether the
container is being contacted by an uncontained process (running with
the user's full privileges), or whether it is being contacted by a
contained process (in a container created by Flatpak or Snap).
* dconf: Currently, a contained app either has full read/write access
to dconf, or no access. It should have read/write access to its own
subtree of dconf configuration space, and no access to the rest.
At the moment, Flatpak runs a D-Bus proxy (xdg-dbus-proxy) for each app instance that has access to D-Bus, connects to the appropriate bus on the app's behalf, and passes messages through. That proxy is in a container similar to the actual app instance, but not actually the same container; it is trusted to not pass messages through that it shouldn't pass through. Portals identify the contained app by reading the proxy's `/proc/$pid/root/.flatpak-info`, which is Flatpak-specific. Reading through `/proc/$pid/root` like that also has an inherent race condition: if the process exits at exactly the wrong time, and the process ID space (which is only 15 bits) wraps around such that an uncontained or differently-contained process gets the same process ID allocated for it, then the portal would see the differently-contained process's identity instead. Flatpak is effectively trusting the proxy not to exit at a sufficiently inconvenient time.
Meanwhile, Snap does its sandboxing with AppArmor, on kernels where it is enabled both at compile-time (Ubuntu, openSUSE, Debian, Debian derivatives like Tails) and at runtime (Ubuntu, openSUSE and Tails, but not Debian by default). Ubuntu's kernel has extra AppArmor features that haven't yet gone upstream, some of which provide reliable app identification via LSM labels, which `dbus-daemon` can learn by querying its `AF_UNIX` socket; however, other kernels like the ones in openSUSE and Debian don't have those. The access-control (AppArmor *mediation*) is implemented in upstream dbus-daemon, but again doesn't work portably: the kernel needs to have the necessary non-upstream features available, and they need to have been enabled at compile time and at runtime. The AppArmor rules are also somewhat inflexible: they are fixed at load time, and do not have access to a lot of useful domain-specific information. They're enough for rules like "allow talking to portals A, B and C", but not really enough for dconf's needs.
@smcv discussed this with Allison Lortie and Alexander Larsson at the GTK Hackfest a long time ago, and we came up with a plan for obsoleting the Flatpak proxy by enhancing dbus-daemon.
As of 2023, this work did not reach a point where it could genuinely obsolete xdg-dbus-proxy. There has been a lot of design bikeshedding, and as of late 2021 when we were starting to think about freezing dbus 1.14.x, @smcv was not confident that it had the required multi-year stability.
Migration from freedesktop.org Bugzilla to freedesktop.org Gitlab has not helped the readability of this issue either.
In the short term (for 1.16.0) @smcv is hoping to provide a subset of this interface that has the "secure identification" layer, but still relies on Flatpak's xdg-dbus-proxy for the filtering layer, and does not have advanced or elaborate functionality.
## Dependencies for basic functionality
See #477.
## Dependencies if we want to obsolete xdg-dbus-proxy
Fully obsoleting xdg-dbus-proxy requires message filtering/policy: #185, originally [fdo#101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902). This is not going to be quick to implement, and is out of scope for #477.
## Other nice-to-haves
* #186
* #188
* #189
* #206
## Other related issues
* [Original bug (fdo#100344)](https://bugs.freedesktop.org/show_bug.cgi?id=100344)