The files are named too generically, so that they might conflict with
the upstream project headers. Hence, let's add a "-util" suffix, to
clarify that this are just our utility headers and not any official
upstream headers.
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
This reverts commit d4d00020d6. The idea of
the commit is broken and needs to be reworked. We really cannot reduce
the bus-addresses to a single address. We always will have systemd with
native clients and legacy clients at the same time, so we also need both
addresses at the same time.
We use dashes in our bloom-tags. Make sure the newly introduced arg0has
tag uses the same style.
Note that the external dbus-tags don't use dashes, though. They are
defined in the spec and we need to keep compatibility there.
Previously, sd-bus inofficially already supported bus matches that
tested a string against an array of strings ("as"). This was done via an
enhanced way to interpret "arg0=" matches. This is problematic however,
since clients have no way to determine if their respective
implementation understood strv matches or not, thus allowing invalid
matches to be installed without a way to detect that.
This patch changes the logic to only allow such matches with a new
"arg0has=" syntax. This has the benefit that non-conforming
implementations will return a parse error and a client application may
thus efficiently detect support for the match type.
Matches of this type are useful for "udev"-like systems that "tag" objects
with a number of strings, and clients need to be able to match against
any of these "tags".
The name "has" takes inspiration from Python's ".has_key()" construct.
If a connection passed KDBUS_HELLO_ACTIVATOR, it cannot do I/O on the
bus. Hence, we should not treat it as proper peer. To actually query it,
you have to explicitly ask for activators.
This makes kdbus in-line with what dbus-daemon does.
We should not fall back to dbus-1 and connect to the proxy when kdbus
returns an error that indicates that kdbus is running but just does not
accept new connections because of quota limits or something similar.
Using is_kdbus_available() in libsystemd/ requires it to move from
shared/ to libsystemd/.
Based on a patch from David Herrmann:
https://github.com/systemd/systemd/pull/886
We *must not* assume that an entry returned by KDBUS_CMD_LIST only
carries a single KDBUS_ITEM_OWNED_NAME. Similarly, we already parse
multiple such items for message-metadata, so make sure we support the
same on KDBUS_CMD_LIST.
By relying on the kernel to return all names separately, we limit the
kernel API significantly. Stop this and let the kernel decide how to
return its data.
If the caller does not specify arg1 for NameOwnerChanged matches, we
really must take the ID from arg2 or arg3, if provided. They are
guaranteed to be identical to arg1 if either is supplied, but there is no
strict requiredment that arg1 is supplied. Hence, make sure to always
take the more restrictive match. Otherwise, we install rather wide
matches without anyone requiring them.
Make sure we don't install NameOwnerChanged matches if the caller passed
a destination='' match (except if it is the broadcast address). Per spec,
all NameOwnerChanged signals are broadcasts.
Only the NameLost/NameAcquired signals are unicasts, but those are never
received through sd-bus. Instead, the bus-proxy synthesizes them and it
already installs proper matches for them.
Right now, we never install destination matches on kdbus as the kernel did
not support MATCH rules on those. With the introduction of
KDBUS_ITEM_DST_ID we can now match on destination IDs, so add explicit
support for those.
This requires a recent kdbus module to work. However, there seems to be no
user-space that uses "Destination=''" matches, yet, so old kdbus modules
still work fine (we couldn't find any real user).
This is needed to match on unicast signals in bus-proxy. A followup will
add support for this.
DBus spec clearly defines arg0path= to be a two-way matching. That is,
either the matcher or the matchee can be a prefix of the other to match.
This is not possible to implement with bloom-filters. Instead, we'd have
to add a separate filter for each prefix. This is non-trivial, though.
Hence, just skip the match for now and match locally.
This appears to be the right time to do it for SOCK_STREAM
unix sockets.
Also: condition bus_get_owner_creds_dbus1 was reversed. Split
it out to a separate variable for clarity and fix.
https://bugzilla.redhat.com/show_bug.cgi?id=1224211
A number of fields do not apply to all processes, including: there a
processes without a controlling tty, without parent process, without
service, user services or session. To distuingish these cases from the
case where we simply don't have the data, always return ENXIO for them,
while returning ENODATA for the case where we really lack the
information.
Also update the credentials dumping code to show this properly. Fields
that are known but do not apply are now shown as "n/a".
Note that this also changes some of the calls in process-util.c and
cgroup-util.c to return ENXIO for these cases.
After some reconsideration, we decided to move the binary protocol
back to 64-bit wide UIDs and GIDs. After all, it should be possible
to redefine [gu]id_t to uint64_t and things should continue to
work. As we want to avoid such data types in kdbus.h, let's move
back to 64-bit values and be safe.
In sd-bus, we have to do a translation between uint64_t and gid_t
now for supplementary gids.
Some inline comments have also been updated in kdbus upstream.
Follow two small changes in the kdbus API:
* Flags are now returned in cmd->return_flags by KDBUS_CMD_NAME_ACQUIRE
* struct kdbus_item_list has been dropped. The information stored in
this struct was redundant since awhile already, as all commands
report their returned slice size anyway.
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
After all it is now much more like strjoin() than strappend(). At the
same time, add support for NULL sentinels, even if they are normally not
necessary.
If we scale our buffer to be wide enough for the format string, we
should expect that the calculation was correct.
char_array_0() invocations are removed, since snprintf nul-terminates
the output in any case.
A similar wrapper is used for strftime calls, but only in timedatectl.c.
If we set SD_BUS_CREDS_AUGMENT, we *need* the PID from the kernel so we
can lookup further information from /proc. However, we *must* set
SD_BUS_CREDS_PIDS in "mask", otherwise, our creds-collector will never
actually copy the pid into "sd_bus_creds". Fix this, so
SD_BUS_CREDS_AUGMENT works even if SD_BUS_CREDS_PID is not specified by
the caller.
Whenever a process performs an action on an object, the kernel uses the
EUID of the process to do permission checks and to apply on any newly
created objects. The UID of a process is only used if someone *ELSE* acts
on the process. That is, the UID of a process defines who owns the
process, the EUID defines what privileges are used by this process when
performing an action.
Process limits, on the other hand, are always applied to the real UID, not
the effective UID. This is, because a process has a user object linked,
which always corresponds to its UID. A process never has a user object
linked for its EUID. Thus, accounting (and limits) is always done on the
real UID.
This commit fixes all sd-bus users to use the EUID when performing
privilege checks and alike. Furthermore, it fixes unix-creds to be parsed
as EUID, not UID (as the kernel always takes the EUID on UDS). Anyone
using UID (eg., to do user-accounting) has to fall back to the EUID as UDS
does not transmit the UID.
The number of available caps can be read from
/proc/sys/kernel/cap_last_cap during runtime. Our helper cap_last_cap()
does that, so there's no reason to remember the size of any capability
cache. We can just pre-allocate arrays with a suitable size for all
available caps and reject any higher caps.
The kernel capability API uses u32 as base so make sure we do the same.
Note that this is specified by POSIX, so it's unlikely to change.
Sync up with recent kdbus changed:
* several ioctls gained .size and .items members (but still unused)
* CMD_SEND gained its own ioctl structure
* several members of kdbus_msg were dropped as they were only used during
SEND, not during RECV etc.
* CMD_RECV and CMD_SEND now share a kdbus_reply member which contains the
offset and size of the returned message.
