dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2023-09-06T17:04:39Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/205Containers message filtering/policy (#101902): control over receiving broadcasts2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over receiving broadcasts## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105660)](https://bugs.freedesktop.org/show_bug.cgi?id=105660)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105660)](https://bugs.freedesktop.org/show_bug.cgi?id=105660)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
[ ] Rules can allow connections in the container instance to receive broadcasts
[ ] from any bus name
[ ] from a subtree of bus names
[ ] from a specific bus name
[ ] from any object path
[ ] from a subtree of object paths
[ ] from a specific object path
[ ] from any interface
[ ] from a specific interface
[ ] a specific signal in a specific interface
[ ] Broadcasts can't normally contain Unix fds
Version: git master
### Depends on
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/204Containers message filtering/policy (#101902): control over messages leaving ...2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over messages leaving container## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105659)](https://bugs.freedesktop.org/show_bug.cgi?id=105659)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105659)](https://bugs.freedesktop.org/show_bug.cgi?id=105659)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
[ ] Can add rules to give a contained app permission to send method calls
[ ] ... to any bus name
[ ] ... to specified bus names
[ ] ... only if they are to a specified object path
[ ] ... only if they are to a specified object path hierarchy (OBJECT_PATH_IS_SUBTREE flag)
[ ] ... only if they are on a specified interface
[ ] ... only if they are a specified member of a specified interface
[ ] Sending Unix fds is only allowed if a rule with the SEND_UNIX_FDS flag allows it
[ ] Can add rules to give a contained app permission to send unicast signals
[ ] ... to any bus name
[ ] ... to specified bus names
[ ] ... only if they are from a specified object path
[ ] ... only if they are from a specified object path hierarchy
[ ] ... only if they are from a specified interface
[ ] ... only if they are a specified member of a specified interface (INTERFACE_IS_REALLY_MEMBER flag, or some better name)
[ ] Can add rules to give a contained app permission to send broadcast signals outside its own container instance
[ ] ... only if they are from a specified object path
[ ] ... only if they are from a specified object path hierarchy
[ ] ... only if they are from a specified interface
[ ] ... only if they are a specified member of a specified interface
[ ] Failing to send a broadcast does not return an error to the caller at all
[ ] Failing to send a broadcast to an interested connection does notify monitors
[ ] Each method call sent can have exactly 1 reply, unless it has NO_REPLY_EXPECTED
[ ] If the sender cannot even SEE the proposed destination, the error returned does not allow discovery of whether the destination was even present (ideally check this before even finding out whether the destination exists)
[ ] Unit tests
To be designed
==============
One of these:
* ACTIVATE flag controls StartServiceByName()
* You can StartServiceByName(foo) if there is any method call that
you would be allowed to send to foo
Out of scope
============
* Receiving non-reply messages
Version: git master
### Depends on
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/203Containers message filtering/policy (#101902): SEE access control2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): SEE access control## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105658)](https://bugs.freedesktop.org/show_bug.cgi?id=105658)**
## Description
+++ This bug was initially created as a clone of Bug #101902 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105658)](https://bugs.freedesktop.org/show_bug.cgi?id=105658)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Implement the SEE access-control model as a step towards Bug #101902.
* Allow list can contain tuples with SEE flag and bus name
* If a contained peer calls ListActivatableNames, ListNames,
NameHasOwner or GetNameOwner, names that it can SEE are not
treated as if they didn't exist
* A contained peer can see NameOwnerChanged signals where the
name in question is one that it can SEE
* If a contained peer can SEE a well-known name, then it can SEE the unique
name that owns that well-known name too (the primary owner)
* If a contained peer receives a method call or unicast signal from
outside the container, then it receives SEE access to the sender's unique name
* Add a named parameter or a special allow rule that lets the contained peer SEE every unique name
* Bus name can be "" to match anything
* Bus name can be combined with BUS_NAME_IS_SUBTREE flag to match like arg0namespace
* Object path is ignored for SEE checks
* Interface is ignored for SEE checks
To be designed
==============
One of these:
* If a contained peer can SEE a well-known name, then it can SEE every
unique name in the queue for that well-known name
* If a contained peer can SEE a well-known name, this does not affect
whether it can SEE unique names that are in the queue for the
well-known name but are not the primary owner
Version: git master
### Depends on
* [Bug 105656](https://bugs.freedesktop.org/show_bug.cgi?id=105656)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)
* [Bug 105659](https://bugs.freedesktop.org/show_bug.cgi?id=105659)
* [Bug 105660](https://bugs.freedesktop.org/show_bug.cgi?id=105660)https://gitlab.freedesktop.org/dbus/dbus/-/issues/202Containers message filtering/policy (#101902): control over receiving Unix fds2023-09-06T17:04:39ZBugzilla Migration UserContainers message filtering/policy (#101902): control over receiving Unix fds## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105657)](https://bugs.freedesktop.org/show_bug.cgi?id=105657)**
## Description
+++ This bug was initially created as a clone of Bug #101902...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#105657)](https://bugs.freedesktop.org/show_bug.cgi?id=105657)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
Allow rules (see Bug #101902) need to be able to opt-in to a container instance receiving Unix fds.
To be designed
==============
One of:
* The rule's object path, bus name, interface must match the message
* The bus name must match but the object path and interface must be non-specific
* The object path, bus name, interface must be non-specific
One of:
* The flag works for both method calls and unicast signals and does not differentiate (this is a bit odd if filtering by path or interface is allowed, because they have different meanings in each direction)
* The flag is split into RECEIVE_UNIX_FD_METHOD_CALLS and RECEIVE_UNIX_FD_SIGNALS
* RECEIVE_UNIX_FDS is assumed to mean method calls because putting fds in signals is silly
Out of scope
============
* Sending Unix fds
* Receiving Unix fds in broadcast signals (which is ridiculous)
Version: git master
### Depends on
* [Bug 105656](https://bugs.freedesktop.org/show_bug.cgi?id=105656)
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)https://gitlab.freedesktop.org/dbus/dbus/-/issues/201Containers message filtering/policy (#101902): basic, strict policy2024-02-23T20:15:34ZBugzilla Migration UserContainers message filtering/policy (#101902): basic, strict policy## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105656)](https://bugs.freedesktop.org/show_bug.cgi?id=105656)**
## Description
+++ This bug was initially created as a clone of Bug #101902 ++...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#105656)](https://bugs.freedesktop.org/show_bug.cgi?id=105656)**
## Description
+++ This bug was initially created as a clone of Bug #101902 +++
As a starting point for T7327, implement the most basic form of the Allow named argument: an empty list of things to allow.
This is planned to have the following semantics:
* Things that are unconditionally allowed are allowed
* Anything that is conditional is forbidden
Version: git master
### Blocking
* [Bug 101902](https://bugs.freedesktop.org/show_bug.cgi?id=101902)
* [Bug 105657](https://bugs.freedesktop.org/show_bug.cgi?id=105657)
* [Bug 105658](https://bugs.freedesktop.org/show_bug.cgi?id=105658)https://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 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/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/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/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/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)