package/dbus-broker: new package
dbus-broker is an alternate implementation of a dbus daemon. It can be
used as a drop-in replacement for the system bus daemon, as well as the
session bus daemon.
dbus-broker is (basically, and as far as we're concerned in Buildroot)
split in two components:
- the actual message bus daemon, that relays messages across clients
- a launcher, which is responsible for setting various aspects of the
bus, like setting the policy et al. and opening the socket(s) the
message bus daemon will have to listen on...
The launcher can only be used in a systemd setup (it makes heavy use of
systemd facilities), while the message bus is generic. However, the
message bus daemon is useless without a launcher. There does not exist a
non-systemd launcher, which makes dbus-broker actually a systemd-only
package; this can be revisited when/if a non-systemd launcher appears.
Note, however, that libdbus is not provided by dbus-broker. People who
want to use dbus-broker as the bus daemon, and need libdbus, will have
to enable both.
If only original dbus is enabled, things stay as they are now. This is
for the moment still the default, though we should change that once
dbus-broker has proven to work.
If only dbus-broker is enabled, it installs the necessary socket
activation units and dbus configuration files. The daemon is not
launched at boot time; instead it is socket-activated when a client
connects to the bus the first time.
If both original dbus and dbus-broker are enabled, we have a conflict
with the configuration files, the socket activation file. Also, original
dbus activates the daemon as a service in multi-user.target.wants, so it
is not socket-activated and dbus-broker would never get the opportunity
to start.
Therefore, original dbus is updated to remove the conflicting files and
the activation of dbus-daemon. Since dbus-broker installs some of the
same file that original dbus removes, we have to add a dependency to
make sure that the ones installed by dbus-broker aren't removed.
If both are installed, it is still possible to revert back to using
original dbus as system bus:
- at build-time: by calling systemctl enable/disable from a
post-build script (preferred), or by providing drop-in units
or presets in an overlay (less preferred) or custom skeleton
(as a last resort),
- at runtime (on a RW filesystem): by calling systemctl
enable/disable
Note about the user: the path to the system bus socket is a so-called
"well-known location": it is expected to be there, by spec. Moving it
elsewhere is going to break existing programs. So, the user running the
system bus daemon must be able to create that socket.
As we may have two packages providing a system bus daemon, they have to
be both able to create the socket, and thus must both be able to write
in the directory containing the socket. And since they can be switched
at runtime, they must be running as the same user.
We can't just reference the original dbus user, so we duplicate the
entry. What is important, is that the user be named 'dbus', as that's
what we use in both cases.
If both original dbus and dbus-broker are selected, the dbus user is
included twice, but the specifications are identical so that's fine.
mkusers will create the user only once.
Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't select systemd; depend on it instead
- only install config files and systemd units without original dbus
- install a user to run the message bus as
- fix licensing info
- entirely reword and extend the commit log
- add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Use dbus-broker as system bus if both are selected.
- Remove conflicting files from dbus installation.
- Simplify symbolic link creation.
- Add comment to remind update of session.conf and system.conf.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
|
|
|
<!-- This configuration file controls the systemwide message bus.
|
|
|
|
|
Add a system-local.conf and edit that rather than changing this
|
|
|
|
|
file directly. -->
|
|
|
|
|
|
|
|
|
|
<!-- Note that there are any number of ways you can hose yourself
|
|
|
|
|
security-wise by screwing up this file; in particular, you
|
|
|
|
|
probably don't want to listen on any more addresses, add any more
|
|
|
|
|
auth mechanisms, run as a different user, etc. -->
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
|
|
|
|
|
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
|
|
|
|
|
<busconfig>
|
|
|
|
|
|
|
|
|
|
<!-- Our well-known bus type, do not change this -->
|
|
|
|
|
<type>system</type>
|
|
|
|
|
|
|
|
|
|
<!-- Run as special user -->
|
|
|
|
|
<user>dbus</user>
|
|
|
|
|
|
2023-07-29 06:14:18 +02:00
|
|
|
<!-- Fork into daemon mode -->
|
|
|
|
|
<fork/>
|
|
|
|
|
|
package/dbus-broker: new package
dbus-broker is an alternate implementation of a dbus daemon. It can be
used as a drop-in replacement for the system bus daemon, as well as the
session bus daemon.
dbus-broker is (basically, and as far as we're concerned in Buildroot)
split in two components:
- the actual message bus daemon, that relays messages across clients
- a launcher, which is responsible for setting various aspects of the
bus, like setting the policy et al. and opening the socket(s) the
message bus daemon will have to listen on...
The launcher can only be used in a systemd setup (it makes heavy use of
systemd facilities), while the message bus is generic. However, the
message bus daemon is useless without a launcher. There does not exist a
non-systemd launcher, which makes dbus-broker actually a systemd-only
package; this can be revisited when/if a non-systemd launcher appears.
Note, however, that libdbus is not provided by dbus-broker. People who
want to use dbus-broker as the bus daemon, and need libdbus, will have
to enable both.
If only original dbus is enabled, things stay as they are now. This is
for the moment still the default, though we should change that once
dbus-broker has proven to work.
If only dbus-broker is enabled, it installs the necessary socket
activation units and dbus configuration files. The daemon is not
launched at boot time; instead it is socket-activated when a client
connects to the bus the first time.
If both original dbus and dbus-broker are enabled, we have a conflict
with the configuration files, the socket activation file. Also, original
dbus activates the daemon as a service in multi-user.target.wants, so it
is not socket-activated and dbus-broker would never get the opportunity
to start.
Therefore, original dbus is updated to remove the conflicting files and
the activation of dbus-daemon. Since dbus-broker installs some of the
same file that original dbus removes, we have to add a dependency to
make sure that the ones installed by dbus-broker aren't removed.
If both are installed, it is still possible to revert back to using
original dbus as system bus:
- at build-time: by calling systemctl enable/disable from a
post-build script (preferred), or by providing drop-in units
or presets in an overlay (less preferred) or custom skeleton
(as a last resort),
- at runtime (on a RW filesystem): by calling systemctl
enable/disable
Note about the user: the path to the system bus socket is a so-called
"well-known location": it is expected to be there, by spec. Moving it
elsewhere is going to break existing programs. So, the user running the
system bus daemon must be able to create that socket.
As we may have two packages providing a system bus daemon, they have to
be both able to create the socket, and thus must both be able to write
in the directory containing the socket. And since they can be switched
at runtime, they must be running as the same user.
We can't just reference the original dbus user, so we duplicate the
entry. What is important, is that the user be named 'dbus', as that's
what we use in both cases.
If both original dbus and dbus-broker are selected, the dbus user is
included twice, but the specifications are identical so that's fine.
mkusers will create the user only once.
Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't select systemd; depend on it instead
- only install config files and systemd units without original dbus
- install a user to run the message bus as
- fix licensing info
- entirely reword and extend the commit log
- add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Use dbus-broker as system bus if both are selected.
- Remove conflicting files from dbus installation.
- Simplify symbolic link creation.
- Add comment to remind update of session.conf and system.conf.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
|
|
|
<!-- We use system service launching using a helper -->
|
|
|
|
|
<standard_system_servicedirs/>
|
|
|
|
|
|
2023-07-29 06:14:18 +02:00
|
|
|
<!-- This is a setuid helper that is used to launch system services -->
|
|
|
|
|
<servicehelper>/usr/libexec/dbus-daemon-launch-helper</servicehelper>
|
|
|
|
|
|
|
|
|
|
<!-- Write a pid file -->
|
|
|
|
|
<pidfile>/run/messagebus.pid</pidfile>
|
|
|
|
|
|
package/dbus-broker: new package
dbus-broker is an alternate implementation of a dbus daemon. It can be
used as a drop-in replacement for the system bus daemon, as well as the
session bus daemon.
dbus-broker is (basically, and as far as we're concerned in Buildroot)
split in two components:
- the actual message bus daemon, that relays messages across clients
- a launcher, which is responsible for setting various aspects of the
bus, like setting the policy et al. and opening the socket(s) the
message bus daemon will have to listen on...
The launcher can only be used in a systemd setup (it makes heavy use of
systemd facilities), while the message bus is generic. However, the
message bus daemon is useless without a launcher. There does not exist a
non-systemd launcher, which makes dbus-broker actually a systemd-only
package; this can be revisited when/if a non-systemd launcher appears.
Note, however, that libdbus is not provided by dbus-broker. People who
want to use dbus-broker as the bus daemon, and need libdbus, will have
to enable both.
If only original dbus is enabled, things stay as they are now. This is
for the moment still the default, though we should change that once
dbus-broker has proven to work.
If only dbus-broker is enabled, it installs the necessary socket
activation units and dbus configuration files. The daemon is not
launched at boot time; instead it is socket-activated when a client
connects to the bus the first time.
If both original dbus and dbus-broker are enabled, we have a conflict
with the configuration files, the socket activation file. Also, original
dbus activates the daemon as a service in multi-user.target.wants, so it
is not socket-activated and dbus-broker would never get the opportunity
to start.
Therefore, original dbus is updated to remove the conflicting files and
the activation of dbus-daemon. Since dbus-broker installs some of the
same file that original dbus removes, we have to add a dependency to
make sure that the ones installed by dbus-broker aren't removed.
If both are installed, it is still possible to revert back to using
original dbus as system bus:
- at build-time: by calling systemctl enable/disable from a
post-build script (preferred), or by providing drop-in units
or presets in an overlay (less preferred) or custom skeleton
(as a last resort),
- at runtime (on a RW filesystem): by calling systemctl
enable/disable
Note about the user: the path to the system bus socket is a so-called
"well-known location": it is expected to be there, by spec. Moving it
elsewhere is going to break existing programs. So, the user running the
system bus daemon must be able to create that socket.
As we may have two packages providing a system bus daemon, they have to
be both able to create the socket, and thus must both be able to write
in the directory containing the socket. And since they can be switched
at runtime, they must be running as the same user.
We can't just reference the original dbus user, so we duplicate the
entry. What is important, is that the user be named 'dbus', as that's
what we use in both cases.
If both original dbus and dbus-broker are selected, the dbus user is
included twice, but the specifications are identical so that's fine.
mkusers will create the user only once.
Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't select systemd; depend on it instead
- only install config files and systemd units without original dbus
- install a user to run the message bus as
- fix licensing info
- entirely reword and extend the commit log
- add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Use dbus-broker as system bus if both are selected.
- Remove conflicting files from dbus installation.
- Simplify symbolic link creation.
- Add comment to remind update of session.conf and system.conf.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
|
|
|
<!-- Enable logging to syslog -->
|
|
|
|
|
<syslog/>
|
|
|
|
|
|
2023-07-29 06:14:18 +02:00
|
|
|
<!-- Only allow socket-credentials-based authentication -->
|
|
|
|
|
<auth>EXTERNAL</auth>
|
|
|
|
|
|
|
|
|
|
<!-- Only listen on a local socket. (abstract=/path/to/socket
|
|
|
|
|
means use abstract namespace, don't really create filesystem
|
|
|
|
|
file; only Linux supports this. Use path=/whatever on other
|
|
|
|
|
systems.) -->
|
|
|
|
|
<listen>unix:path=/run/dbus/system_bus_socket</listen>
|
|
|
|
|
|
package/dbus-broker: new package
dbus-broker is an alternate implementation of a dbus daemon. It can be
used as a drop-in replacement for the system bus daemon, as well as the
session bus daemon.
dbus-broker is (basically, and as far as we're concerned in Buildroot)
split in two components:
- the actual message bus daemon, that relays messages across clients
- a launcher, which is responsible for setting various aspects of the
bus, like setting the policy et al. and opening the socket(s) the
message bus daemon will have to listen on...
The launcher can only be used in a systemd setup (it makes heavy use of
systemd facilities), while the message bus is generic. However, the
message bus daemon is useless without a launcher. There does not exist a
non-systemd launcher, which makes dbus-broker actually a systemd-only
package; this can be revisited when/if a non-systemd launcher appears.
Note, however, that libdbus is not provided by dbus-broker. People who
want to use dbus-broker as the bus daemon, and need libdbus, will have
to enable both.
If only original dbus is enabled, things stay as they are now. This is
for the moment still the default, though we should change that once
dbus-broker has proven to work.
If only dbus-broker is enabled, it installs the necessary socket
activation units and dbus configuration files. The daemon is not
launched at boot time; instead it is socket-activated when a client
connects to the bus the first time.
If both original dbus and dbus-broker are enabled, we have a conflict
with the configuration files, the socket activation file. Also, original
dbus activates the daemon as a service in multi-user.target.wants, so it
is not socket-activated and dbus-broker would never get the opportunity
to start.
Therefore, original dbus is updated to remove the conflicting files and
the activation of dbus-daemon. Since dbus-broker installs some of the
same file that original dbus removes, we have to add a dependency to
make sure that the ones installed by dbus-broker aren't removed.
If both are installed, it is still possible to revert back to using
original dbus as system bus:
- at build-time: by calling systemctl enable/disable from a
post-build script (preferred), or by providing drop-in units
or presets in an overlay (less preferred) or custom skeleton
(as a last resort),
- at runtime (on a RW filesystem): by calling systemctl
enable/disable
Note about the user: the path to the system bus socket is a so-called
"well-known location": it is expected to be there, by spec. Moving it
elsewhere is going to break existing programs. So, the user running the
system bus daemon must be able to create that socket.
As we may have two packages providing a system bus daemon, they have to
be both able to create the socket, and thus must both be able to write
in the directory containing the socket. And since they can be switched
at runtime, they must be running as the same user.
We can't just reference the original dbus user, so we duplicate the
entry. What is important, is that the user be named 'dbus', as that's
what we use in both cases.
If both original dbus and dbus-broker are selected, the dbus user is
included twice, but the specifications are identical so that's fine.
mkusers will create the user only once.
Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't select systemd; depend on it instead
- only install config files and systemd units without original dbus
- install a user to run the message bus as
- fix licensing info
- entirely reword and extend the commit log
- add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Use dbus-broker as system bus if both are selected.
- Remove conflicting files from dbus installation.
- Simplify symbolic link creation.
- Add comment to remind update of session.conf and system.conf.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
|
|
|
<policy context="default">
|
|
|
|
|
<!-- All users can connect to system bus -->
|
|
|
|
|
<allow user="*"/>
|
|
|
|
|
|
|
|
|
|
<!-- Holes must be punched in service configuration files for
|
|
|
|
|
name ownership and sending method calls -->
|
|
|
|
|
<deny own="*"/>
|
|
|
|
|
<deny send_type="method_call"/>
|
|
|
|
|
|
|
|
|
|
<!-- Signals and reply messages (method returns, errors) are allowed
|
|
|
|
|
by default -->
|
|
|
|
|
<allow send_type="signal"/>
|
|
|
|
|
<allow send_requested_reply="true" send_type="method_return"/>
|
|
|
|
|
<allow send_requested_reply="true" send_type="error"/>
|
|
|
|
|
|
|
|
|
|
<!-- All messages may be received by default -->
|
|
|
|
|
<allow receive_type="method_call"/>
|
|
|
|
|
<allow receive_type="method_return"/>
|
|
|
|
|
<allow receive_type="error"/>
|
|
|
|
|
<allow receive_type="signal"/>
|
|
|
|
|
|
|
|
|
|
<!-- Allow anyone to talk to the message bus -->
|
|
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus" />
|
|
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus.Introspectable"/>
|
|
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus.Properties"/>
|
2023-07-29 06:14:18 +02:00
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus.Containers1"/>
|
package/dbus-broker: new package
dbus-broker is an alternate implementation of a dbus daemon. It can be
used as a drop-in replacement for the system bus daemon, as well as the
session bus daemon.
dbus-broker is (basically, and as far as we're concerned in Buildroot)
split in two components:
- the actual message bus daemon, that relays messages across clients
- a launcher, which is responsible for setting various aspects of the
bus, like setting the policy et al. and opening the socket(s) the
message bus daemon will have to listen on...
The launcher can only be used in a systemd setup (it makes heavy use of
systemd facilities), while the message bus is generic. However, the
message bus daemon is useless without a launcher. There does not exist a
non-systemd launcher, which makes dbus-broker actually a systemd-only
package; this can be revisited when/if a non-systemd launcher appears.
Note, however, that libdbus is not provided by dbus-broker. People who
want to use dbus-broker as the bus daemon, and need libdbus, will have
to enable both.
If only original dbus is enabled, things stay as they are now. This is
for the moment still the default, though we should change that once
dbus-broker has proven to work.
If only dbus-broker is enabled, it installs the necessary socket
activation units and dbus configuration files. The daemon is not
launched at boot time; instead it is socket-activated when a client
connects to the bus the first time.
If both original dbus and dbus-broker are enabled, we have a conflict
with the configuration files, the socket activation file. Also, original
dbus activates the daemon as a service in multi-user.target.wants, so it
is not socket-activated and dbus-broker would never get the opportunity
to start.
Therefore, original dbus is updated to remove the conflicting files and
the activation of dbus-daemon. Since dbus-broker installs some of the
same file that original dbus removes, we have to add a dependency to
make sure that the ones installed by dbus-broker aren't removed.
If both are installed, it is still possible to revert back to using
original dbus as system bus:
- at build-time: by calling systemctl enable/disable from a
post-build script (preferred), or by providing drop-in units
or presets in an overlay (less preferred) or custom skeleton
(as a last resort),
- at runtime (on a RW filesystem): by calling systemctl
enable/disable
Note about the user: the path to the system bus socket is a so-called
"well-known location": it is expected to be there, by spec. Moving it
elsewhere is going to break existing programs. So, the user running the
system bus daemon must be able to create that socket.
As we may have two packages providing a system bus daemon, they have to
be both able to create the socket, and thus must both be able to write
in the directory containing the socket. And since they can be switched
at runtime, they must be running as the same user.
We can't just reference the original dbus user, so we duplicate the
entry. What is important, is that the user be named 'dbus', as that's
what we use in both cases.
If both original dbus and dbus-broker are selected, the dbus user is
included twice, but the specifications are identical so that's fine.
mkusers will create the user only once.
Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't select systemd; depend on it instead
- only install config files and systemd units without original dbus
- install a user to run the message bus as
- fix licensing info
- entirely reword and extend the commit log
- add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Use dbus-broker as system bus if both are selected.
- Remove conflicting files from dbus installation.
- Simplify symbolic link creation.
- Add comment to remind update of session.conf and system.conf.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
|
|
|
<!-- But disallow some specific bus services -->
|
|
|
|
|
<deny send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus"
|
|
|
|
|
send_member="UpdateActivationEnvironment"/>
|
|
|
|
|
<deny send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus.Debug.Stats"/>
|
|
|
|
|
<deny send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.systemd1.Activator"/>
|
|
|
|
|
</policy>
|
|
|
|
|
|
|
|
|
|
<!-- Only systemd, which runs as root, may report activation failures. -->
|
|
|
|
|
<policy user="root">
|
|
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.systemd1.Activator"/>
|
|
|
|
|
</policy>
|
|
|
|
|
|
|
|
|
|
<!-- root may monitor the system bus. -->
|
|
|
|
|
<policy user="root">
|
|
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus.Monitoring"/>
|
|
|
|
|
</policy>
|
|
|
|
|
|
|
|
|
|
<!-- If the Stats interface was enabled at compile-time, root may use it.
|
|
|
|
|
Copy this into system.local.conf or system.d/*.conf if you want to
|
|
|
|
|
enable other privileged users to view statistics and debug info -->
|
|
|
|
|
<policy user="root">
|
|
|
|
|
<allow send_destination="org.freedesktop.DBus"
|
|
|
|
|
send_interface="org.freedesktop.DBus.Debug.Stats"/>
|
|
|
|
|
</policy>
|
|
|
|
|
|
2023-07-29 06:14:18 +02:00
|
|
|
<!-- Include legacy configuration location -->
|
|
|
|
|
<include ignore_missing="yes">/etc/dbus-1/system.conf</include>
|
package/dbus-broker: new package
dbus-broker is an alternate implementation of a dbus daemon. It can be
used as a drop-in replacement for the system bus daemon, as well as the
session bus daemon.
dbus-broker is (basically, and as far as we're concerned in Buildroot)
split in two components:
- the actual message bus daemon, that relays messages across clients
- a launcher, which is responsible for setting various aspects of the
bus, like setting the policy et al. and opening the socket(s) the
message bus daemon will have to listen on...
The launcher can only be used in a systemd setup (it makes heavy use of
systemd facilities), while the message bus is generic. However, the
message bus daemon is useless without a launcher. There does not exist a
non-systemd launcher, which makes dbus-broker actually a systemd-only
package; this can be revisited when/if a non-systemd launcher appears.
Note, however, that libdbus is not provided by dbus-broker. People who
want to use dbus-broker as the bus daemon, and need libdbus, will have
to enable both.
If only original dbus is enabled, things stay as they are now. This is
for the moment still the default, though we should change that once
dbus-broker has proven to work.
If only dbus-broker is enabled, it installs the necessary socket
activation units and dbus configuration files. The daemon is not
launched at boot time; instead it is socket-activated when a client
connects to the bus the first time.
If both original dbus and dbus-broker are enabled, we have a conflict
with the configuration files, the socket activation file. Also, original
dbus activates the daemon as a service in multi-user.target.wants, so it
is not socket-activated and dbus-broker would never get the opportunity
to start.
Therefore, original dbus is updated to remove the conflicting files and
the activation of dbus-daemon. Since dbus-broker installs some of the
same file that original dbus removes, we have to add a dependency to
make sure that the ones installed by dbus-broker aren't removed.
If both are installed, it is still possible to revert back to using
original dbus as system bus:
- at build-time: by calling systemctl enable/disable from a
post-build script (preferred), or by providing drop-in units
or presets in an overlay (less preferred) or custom skeleton
(as a last resort),
- at runtime (on a RW filesystem): by calling systemctl
enable/disable
Note about the user: the path to the system bus socket is a so-called
"well-known location": it is expected to be there, by spec. Moving it
elsewhere is going to break existing programs. So, the user running the
system bus daemon must be able to create that socket.
As we may have two packages providing a system bus daemon, they have to
be both able to create the socket, and thus must both be able to write
in the directory containing the socket. And since they can be switched
at runtime, they must be running as the same user.
We can't just reference the original dbus user, so we duplicate the
entry. What is important, is that the user be named 'dbus', as that's
what we use in both cases.
If both original dbus and dbus-broker are selected, the dbus user is
included twice, but the specifications are identical so that's fine.
mkusers will create the user only once.
Finally, the licensing terms are pretty trivial for dbus-broker itself,
but it makes use of third-party code that it inherits as git submodules
(that are bundled in the release archive). Thus the licensing is a bit
convoluted... The third-party codes claim to be licensed as "Apache-2.0
and LGP-2.1+" in their AUTHORS files, but at the same time claim
"**Apache-2.0** OR **LGPL-2.1-or-later**" in their README files. The
individual source files (that are used) do not seem to have any
licensing header to clarify the situation. So we represent the situation
with "Apache-2.0 and/or LGPL-2.1+".
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- don't select systemd; depend on it instead
- only install config files and systemd units without original dbus
- install a user to run the message bus as
- fix licensing info
- entirely reword and extend the commit log
- add myself to DEVELOPERS as well
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Use dbus-broker as system bus if both are selected.
- Remove conflicting files from dbus installation.
- Simplify symbolic link creation.
- Add comment to remind update of session.conf and system.conf.
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-09 23:16:47 +01:00
|
|
|
|
|
|
|
|
<!-- The defaults for these limits are hard-coded in dbus-daemon.
|
|
|
|
|
Some clarifications:
|
|
|
|
|
Times are in milliseconds (ms); 1000ms = 1 second
|
|
|
|
|
133169152 bytes = 127 MiB
|
|
|
|
|
33554432 bytes = 32 MiB
|
|
|
|
|
150000ms = 2.5 minutes -->
|
|
|
|
|
<!-- <limit name="max_incoming_bytes">133169152</limit> -->
|
|
|
|
|
<!-- <limit name="max_incoming_unix_fds">64</limit> -->
|
|
|
|
|
<!-- <limit name="max_outgoing_bytes">133169152</limit> -->
|
|
|
|
|
<!-- <limit name="max_outgoing_unix_fds">64</limit> -->
|
|
|
|
|
<!-- <limit name="max_message_size">33554432</limit> -->
|
|
|
|
|
<!-- <limit name="max_message_unix_fds">16</limit> -->
|
|
|
|
|
<!-- <limit name="service_start_timeout">25000</limit> -->
|
|
|
|
|
<!-- <limit name="auth_timeout">5000</limit> -->
|
|
|
|
|
<!-- <limit name="pending_fd_timeout">150000</limit> -->
|
|
|
|
|
<!-- <limit name="max_completed_connections">2048</limit> -->
|
|
|
|
|
<!-- <limit name="max_incomplete_connections">64</limit> -->
|
|
|
|
|
<!-- <limit name="max_connections_per_user">256</limit> -->
|
|
|
|
|
<!-- <limit name="max_pending_service_starts">512</limit> -->
|
|
|
|
|
<!-- <limit name="max_names_per_connection">512</limit> -->
|
|
|
|
|
<!-- <limit name="max_match_rules_per_connection">512</limit> -->
|
|
|
|
|
<!-- <limit name="max_replies_per_connection">128</limit> -->
|
|
|
|
|
|
|
|
|
|
<!-- Config files are placed here that among other things, punch
|
|
|
|
|
holes in the above policy for specific services. -->
|
|
|
|
|
<includedir>system.d</includedir>
|
|
|
|
|
|
|
|
|
|
<includedir>/etc/dbus-1/system.d</includedir>
|
|
|
|
|
|
|
|
|
|
<!-- This is included last so local configuration can override what's
|
|
|
|
|
in this standard file -->
|
|
|
|
|
<include ignore_missing="yes">/etc/dbus-1/system-local.conf</include>
|
|
|
|
|
|
|
|
|
|
<include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
|
|
|
|
|
|
|
|
|
|
</busconfig>
|
