dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2022-05-20T12:08:31Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/196Expose group list from SO_PEERGROUPS in GetConnectionCredentials()2020-01-23T15:16:14ZBugzilla Migration UserExpose group list from SO_PEERGROUPS in GetConnectionCredentials()## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104657)](https://bugs.freedesktop.org/show_bug.cgi?id=104657)**
## Description
+++ This bug was initially created as a clone of Bug #103737...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104657)](https://bugs.freedesktop.org/show_bug.cgi?id=104657)**
## Description
+++ This bug was initially created as a clone of Bug #103737 +++
Recent Linux kernels (4.13+) allow for getting a list of auxiliary groups of a socket peer in a race-free way using the SO_PEERGROUPS getsockopt option. Bug #103737 tracks the use of that option in dbus.
If anyone (maybe polkit?) cares about this information, we could add UnixGroupIDs (ARRAY of UINT32) to GetConnectionCredentials().
If we do, then I think its semantics should be that this field is only present when we can discover the other process' complete list of groups, such as on Linux 4.13+ with SO_PEERGROUPS. On platforms where we can only find the primary group ID (like older Linux with SO_PEERCRED) I don't think we should expose any group information at all, because that's needlessly confusing.
I also don't think the bus API should expose the group list that we get from getgrouplist(), to give callers that care about it a way to distinguish between true facts ("the peer definitely had exactly these groups at the time the connection was established") and conjecture ("the peer has uid 1000 so we think it probably has all the groups that uid 1000 would have if they logged in"). If the caller wants to use the same best-guess via getgrouplist() that older/non-Linux dbus-daemon does, then they can implement that themselves.
Version: git master
### Depends on
* [Bug 103737](https://bugs.freedesktop.org/show_bug.cgi?id=103737)https://gitlab.freedesktop.org/dbus/dbus/-/issues/197Documentation tutorial2018-10-15T13:29:50ZBugzilla Migration UserDocumentation tutorial## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104947)](https://bugs.freedesktop.org/show_bug.cgi?id=104947)**
## Description
This is an Introduction to DBus: https://www.freedesktop.org/wiki/In...## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#104947)](https://bugs.freedesktop.org/show_bug.cgi?id=104947)**
## Description
This is an Introduction to DBus: https://www.freedesktop.org/wiki/IntroductionToDBus/
This is a Tutorial to DBus: https://dbus.freedesktop.org/doc/dbus-tutorial.html .
Together they are confusing and repeat each other.
The former
* shall contain a reference to the later,
* In Buses-section, 2nd paragraph, state that DCOP was used in KDE up to version 3
* In the Proxies-section I propose changing the beginning to "Objects on the other end on the bus can be accessed..." to be the opposite of the section in the Objects-section "One end of any exchange on a bus will always be a ... called an onject". So at the end the documentation shall read "one end is object, other end is proxy", except I don't understood things correctly.
* Section 'Signals' first paragraph, third sentence. I propose inserting the work "proxy", so that it reads "Client processes (proxies) can register an interest..." to make clear that a client process is the same as proxy.https://gitlab.freedesktop.org/dbus/dbus/-/issues/198Stop using selinux_set_mapping() function2021-12-17T13:42:06ZBugzilla Migration UserStop using selinux_set_mapping() function## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105330)](https://bugs.freedesktop.org/show_bug.cgi?id=105330)**
## Description
Hi,
ATM, when selinux_set_mapping() fails due to an inc...## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105330)](https://bugs.freedesktop.org/show_bug.cgi?id=105330)**
## Description
Hi,
ATM, when selinux_set_mapping() fails due to an incomplete policy (or no policy at all) dbus-daemon exits even in permissive mode.
This is a bit a problem for people that are developing their policy or for people that need to recover their machines after a miss configuration as dbus-daemon is part of the boot and login process via logind.
I'm actually wondering if that call is needed at all these days. As we could use, I think, avc_context_to_sid(), string_to_security_class() and string_to_av_perm() to get the needed info.
An other solution would be to use selinux_check_access() instead of avc_has_perm() (selinux_check_access() uses avc_has_perm() internally and the function mentioned above internally), the problem is that way we cannot use the cache, I think again, and we might have a performance hit.
selinux_set_mapping() was introduced by:
commit ba088208bc0c35ca418a097a8482c4a7705f4a43
Author: osmond sun <osmond.sun@gmail.com>
Date: Wed Nov 6 00:53:18 2013 +0800
selinux: Use selinux_set_mapping() to avoid hardcoded constants for policy
Previous to the introduction of selinux_set_mapping(), DBus pulled
constants generated from the system's policy at build time. But this
means it's impossible to replace the system policy without rebuilding
userspace components.
This patch maps from arbitrary class/perm indices used by D-Bus and
the policy values and handles all the translation at runtime on
avc_has_perm() calls.
Bug: https://bugs.freedesktop.org/attachment.cgi?id=88719
Reviewed-By: Colin Walters <walters@verbum.org>
Tested-By: Colin Walters <walters@verbum.org>
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/199Fix dbus-send not returning an error exit code in case an error occured and -...2018-10-15T13:28:21ZBugzilla Migration UserFix dbus-send not returning an error exit code in case an error occured and --print-reply is not set## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105380)](https://bugs.freedesktop.org/show_bug.cgi?id=105380)**
## Description## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105380)](https://bugs.freedesktop.org/show_bug.cgi?id=105380)**
## Descriptionhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/200Do CI builds on MSVC using Appveyor or similar2023-08-14T19:00:11ZBugzilla Migration UserDo CI builds on MSVC using Appveyor or similar## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105521)](https://bugs.freedesktop.org/show_bug.cgi?id=105521)**
## Description
We regularly test that dbus builds successfully as a native ...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105521)](https://bugs.freedesktop.org/show_bug.cgi?id=105521)**
## Description
We regularly test that dbus builds successfully as a native build on Linux, and as a cross-compiled mingw64 build for Windows, by pointing Travis-CI to dbus' semi-official Github mirror. We don't do the same for MSVC builds, which makes it hard to be confident that we haven't broken them.
Appveyor seems to be a Windows equivalent of Travis-CI. I've tried to set up a build there for dbus, but so far it isn't working.
Work in progress (probably doesn't work yet): https://github.com/smcv/dbus/commits/appveyor
I don't really know what I'm doing (I've never set up an Appveyor build before) and trial-and-error is rather slower than on Travis-CI, so if someone has used it before, I'd appreciate a fixed version of the build.
Version: git master