This is clearly equivalent, and quiets -Wswitch-default.
Based on part of a patch by Thomas Zimmermann.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98191
This was doing no harm (clearing an already-cleared list is a no-op),
but it was also pointless.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99435
Debian stable, Debian testing and Ubuntu LTS provide a reasonable
spectrum of old and new distributions. I'm only doing one build on
each to avoid a combinatorial explosion of options.
The Docker images don't have any deb-src apt sources set up, so don't
use `apt-get build-dep`; just include dependencies manually.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
[smcv: move comment to install script as suggested]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
Taken from the version I added to OSTree.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
set -u forces us to set all variables that we use (for example with the
${foo:=bar} syntax to take an existing value or set a default), or use the
${foo:-bar} syntax to make it explicit that the variable might be unset.
set -o pipefail (which is a bash feature) detects failure in non-last
elements of a pipeline.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
This aligns it with the more generic script based on this one that
I sent to OSTree.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
This realigns it with the script loosely based on this one that I
sent to OSTree.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
This avoids confusion with the meaning of "release" used by
AX_IS_RELEASE. AX_IS_RELEASE is about facts about the source tree,
namely the distinction between releases (tags) and random snapshots.
The build variants in .travis.yml are about facts about the build
being done, namely the distinction between production and
debug/developer builds.
Production builds are sometimes referred to as "release builds",
for example in typical CMake and MSVC build environments, but a
different term seems better here.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
[smcv: cherry-picked from master to dbus-1.10 to get the Travis-CI setup
consistent between the two branches]
This way the link won't expire in future.
Signed-off-by: Simon McVittie <smcv@debian.org>
[smcv: cherry-picked from master to dbus-1.10 to get the Travis-CI setup
consistent between the two branches; it is not strictly needed on dbus-1.10]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: cherry-picked from master to dbus-1.10 to get the Travis-CI setup
consistent between the two branches; it is not strictly needed on dbus-1.10]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: cherry-picked from master to dbus-1.10 to get the Travis-CI setup
consistent between the two branches; it is not strictly needed on dbus-1.10]
Also don't try to clean up a process we didn't start.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
We need libapparmor 2.10 for the test, but not for the actual
functionality, for which 2.8.95 is enough. In particular this lets
us compile with AppArmor enabled on Ubuntu 14.04, which is still
the newest host platform available on travis-ci.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
We are not going to fix the inconsistent tab/space indentation in a
stable branch just to keep gcc happy.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is a workaround for
<https://bugs.freedesktop.org/show_bug.cgi?id=95263>. If a service
sends a file descriptor sufficiently frequently that its queue of
messages never goes down to 0 fds pending, then it will eventually be
disconnected. logind is one such service.
We do not currently have a good solution for this: the proposed
patches either don't work, or reintroduce a denial of service
security vulnerability (CVE-2014-3637). Neither seems desirable.
However, we can avoid the worst symptoms by trusting uid 0 not to be
malicious.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95263
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1591411
Reviewed-by: Łukasz Zemczak
Tested-by: Ivan Kozik
Tested-by: Finn Herpich
Tested-by: autostatic
Tested-by: Ben Parafina
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
(cherry picked from commit d5fae1db78)
[smcv: omit the test/dbus-daemon.c part, which does not apply unless
a363822f5f is also applied]
This is either a denial-of-service attempt, a pathological performance
problem or a dbus-daemon bug. Sysadmins should be told about any of
these.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86442
[smcv: add units to timeout: it is in milliseconds]
Signed-off-by: Simon McVittie <smcv@debian.org>
(cherry picked from commit 05cb619f0a)
This requires libapparmor 2.10, for aa_features_new_from_kernel()
and related functions.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
Because the recipient process is not yet available, we have to make some
assumption about its AppArmor profile. Parsing the first word of
the Exec value and then chasing symlinks seems like too much magic,
so I've gone for something more explicit. If the .service file contains
AssumedAppArmorLabel=/foo/bar
then we will do the AppArmor query on the assumption that the recipient
AppArmor label will be as stated. Otherwise, we will do a query
with an unspecified label, which means that AppArmor rules that do
specify a peer label will never match it.
Regardless of the result of this query, we will do an independent
AppArmor query when the activation has actually happened, this time
with the correct peer label; that second query will still be used
to decide whether to deliver the message. As a result, if this change
has any effect, it is to make the bus more restrictive; it does not
allow anything that would previously have been denied.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
We specifically do not check recipient policies, because
the recipient policy is based on properties of the
recipient process (in particular, its uid), which we do
not necessarily know until we have already started it.
In this initial implementation we do not check LSMs either,
because we cannot know what LSM context the recipient process
is going to have. However, LSM support will need to be added
to make this feature useful, because StartServiceByName is
normally allowed in non-LSM environments, and is more
powerful than auto-activation anyway.
The StartServiceByName method does not go through this check,
because if access to that method has been granted, then
it's somewhat obvious that you can start arbitrary services.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
This avoids installing the build-dependencies for dbus and its tests,
then uninstalling them all because they rely on libraries whose versions
are older than the ones needed by wine:i386 (and apparently apt prefers
to remove those libraries rather than upgrade them). Doing it this way
round seems to convince apt to do the right thing.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Clarify its intended behaviour in two situations:
• For interfaces which have no properties.
• Where some properties are not visible to the caller (due to access
control, for example).
The intention here is for this behaviour to be mandatory, but given that
this is quite late on in the specification’s life, and various D-Bus
libraries like dbus-glib and telepathy-glib cannot support access
control at a per-property level, for example. GDBus can, although it’s
questionable whether this is a good idea. Deliberately leave the
specification open to allow access control at a higher level as well
(such as per-(object, interface)).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36190
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Using versioned names here reinforces the advice given in
<https://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning>.
I haven't added versions to the sample parameters "com.example.tea" and
"com.example.cappuccino" for methods that query information about
names, on the basis that I assume they are more likely to be intended
to represent an implementation than an API.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98671
We didn't say that SystemdService existed. Now we do, together with
enough context to make it make sense.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98671
For something we recommend, that is important enough to have its own
header flag, it doesn't have very good documentation. Redo the text
to suggest that auto-starting is the normal thing and
StartServiceByName is the oddity. That's usually a good principle
to follow, since it dodges time-of-check/time-of-use issues, and the
method call that you presumably wanted to do needs to handle errors
anyway.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98671
The spec previously mentioned that CORBA calls this activation, but
did not explicitly say that D-Bus has copied this jargon term.
It's 2016, and developers are probably more likely to be familiar
with D-Bus than with CORBA at this point: explicitly say that *our*
jargon term for this action is activation.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98671
This is a workaround for
<https://bugs.freedesktop.org/show_bug.cgi?id=95263>. If a service
sends a file descriptor sufficiently frequently that its queue of
messages never goes down to 0 fds pending, then it will eventually be
disconnected. logind is one such service.
We do not currently have a good solution for this: the proposed
patches either don't work, or reintroduce a denial of service
security vulnerability (CVE-2014-3637). Neither seems desirable.
However, we can avoid the worst symptoms by trusting uid 0 not to be
malicious.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95263
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1591411
Reviewed-by: Łukasz Zemczak
Tested-by: Ivan Kozik
Tested-by: Finn Herpich
Tested-by: autostatic
Tested-by: Ben Parafina
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
