The test-barrier binary uses real-time alarms and timeouts to test for
races in the thread-barrier implementation. Hence, if your system is under
high load and your scheduler decides to not run test-barrier for
>BASE_TIME, then the tests are likely to fail.
Two options:
1) Increase BASE_TIME. This will make the test take significantly longer
for no real good. Furthermore, it is still not guaranteed that the
task is scheduled.
2) Don't rely on real-time timers, but use explicit synchronization. This
would basically test one barrier implementation with another.. kinda
ironic.. but maybe something worth looking into.
3) Disable test-barrier by default.
This patch chooses option 3) and makes sure test-barrier only runs if you
pass any argument.
Side note:
test-barrier is written in a way that if it fails under load, but
does not on idle systems, then it is very _unlikely_ that the
barrier implementation is the culprit. Hence, it makes little
sense to run it under load, anyway. It will not improve the test
coverage of barrier.c, but rather the coverage of the test itself.
In kdbus we still have to support org.freedesktop.DBus matches even though
there is no real bus driver. The reason is that bus-control.c turns
NameOwnerChanged matches into proper kdbus matches. If we drop DRIVER
matches early, we will never match on name-changes for kdbus.
Two ways to fix this:
1) Install DRIVER matches on kdbus (which is the simple way our and which
is what this patch does).
2) Properly fix the scope-detection to let NameOwnerChanged matches
through (or better: block anything with Member!=NameOwnerChanged).
This adds man-pages for most of the libudev symbols we export. Similar
symbols are grouped together in a single man-page, with respective links
added. All man-pages contain the full skeleton including NAME, SYNOPSIS,
RETURN VALUE and SEE ALSO. However, most of them still lack the
DESCRIPTION part. This should be copied from the gtkdoc descriptions in
src/libudev/libudev*.[ch]. Any help is welcome! (the whole skeleton is
already done, so it's really just about the prose-part of the man-pages to
be written).
Missing from the man-pages are the following parts:
- udev_set_log_fn()
- udev_[gs]et_log_priority()
- udev_[gs]et_userdata()
- udev_list_entry_foreach()
- udev_device_get_seqnum()
- udev_device_get_usec_since_initialized()
- udev_util_encode_string()
These are considered legacy, afaik. If not, please feel free to add them
now!
Furthermore, udev-hwdb and udev-queue are not documented at all (for the
same reasons).
If we call EPOLL_CTL_DEL, we *REALLY* expect the file-descriptor to be
present in that given epoll-set. We actually track such state via our
s->io.registered flag, so it better be true.
Make sure if that's not true, we treat it similar to assert_return() (ie.,
print a loud warning).
Make sure we never close fds before we drop their related event-source.
This will cause horrible disruptions if the fd-num is re-used by someone
else. Under normal conditions, this should not cause any problems as the
close() will drop the fd from the epoll-set automatically. However, this
changes if you have any child processes with a copy of that fd.
This fixes issue #163.
Background:
If you create an epoll-set via epoll_create() (lets call it 'EFD')
you can add file-descriptors to it to watch for events. Whenever
you call EPOLL_CTL_ADD on a file-descriptor you want to watch, the
kernel looks up the attached "struct file" pointer, that this FD
refers to. This combination of the FD-number and the "struct file"
pointer is used as key to link it into the epoll-set (EFD).
This means, if you duplicate your file-descriptor, you can watch
this file-descriptor, too (because the duplicate will have a
different FD-number, hence, the combination of FD-number and
"struct file" is different as before).
If you want to stop watching an FD, you use EPOLL_CTL_DEL and pass
the FD to the kernel. The kernel again looks up your
file-descriptor in your FD-table to find the linked "struct file".
This FD-number and "struct file" combination is then dropped from
the epoll-set (EFD).
Last, but not least: If you close a file-descriptor that is linked
to an epoll-set, the kernel does *NOTHING* regarding the
epoll-set. This is a vital observation! Because this means, your
epoll_wait() calls will still return the metadata you used to
watch/subscribe your file-descriptor to events.
There is one exception to this rule: If the file-descriptor that
you just close()ed was the last FD that referred to the underlying
"struct file", then _all_ epoll-set watches/subscriptions are
destroyed. Hence, if you never dup()ed your FD, then a simple
close() will also unsubscribe it from any epoll-set.
With this in mind, lets look at fork():
Assume you have an epoll-set (EFD) and a bunch of FDs
subscribed to events on that EFD. If you now call fork(),
the new process gets a copy of your file-descriptor table.
This means, the whole table is copied and the "struct
file" reference of each FD is increased by 1. It is
important to notice that the FD-numbers in the child are
exactly the same as in the parent (eg., FD #5 in the child
refers to the same "struct file" as FD #5 in the parent).
This means, if the child calls EPOLL_CTL_DEL on an FD, the
kernel will look up the linked "struct file" and drop the
FD-number and "struct file" combination from the epoll-set
(EFD). However, this will effectively drop the
subscription that was installed by the parent.
To sum up: even though the child gets a duplicate of the
EFD and all FDs, the subscriptions in the EFD are *NOT*
duplicated!
Now, with this in mind, lets look at what udevd does:
Udevd has a bunch of file-descriptors that it watches in its
sd-event main-loop. Whenever a uevent is received, the event is
dispatched on its workers. If no suitable worker is present, a new
worker is fork()ed to handle the event. Inside of this worker, we
try to free all resources we inherited. However, the fork() call
is done from a call-stack that is never rewinded. Therefore, this
call stack might own references that it drops once it is left.
Those references we cannot deduce from the fork()'ed process;
effectively causing us to leak objects in the worker (eg., the
call to sd_event_dispatch() that dispatched our uevent owns a
reference to the sd_event object it used; and drops it again once
the function is left).
(Another example is udev_monitor_ref() for each 'worker' that is
also inherited by all children; thus keeping the udev-monitor and
the uevent-fd alive in all children (which is the real cause for
bug #163))
(The extreme variant is sd_event_source_unref(), which explicitly
keeps event-sources alive, if they're currently dispatched,
knowing that the dispatcher will free the event once done. But
if the dispatcher is in the parent, the child will never ever
free that object, thus leaking it)
This is usually not an issue. However, if such an object has a
file-descriptor embedded, this FD is left open and never closed in
the child.
In manager_exit(), if we now destroy an object (i.e., close its embedded
file-descriptor) before we destroy its related sd_event_source, then
sd-event will not be able to drop the FD from the epoll-set (EFD). This
is, because the FD is no longer valid at the time we call EPOLL_CTL_DEL.
Hence, the kernel cannot figure out the linked "struct file" and thus
cannot remove the FD-number plus "struct file" combination; effectively
leaving the subscription in the epoll-set.
Since we leak the uevent-fd in the children, they retain a copy of the FD
pointing to the same "struct file". Thus, the EFD-subscription are not
automatically removed by close() (as described above). Therefore, the main
daemon will still get its metadata back on epoll_watch() whenever an event
occurs (even though it already freed the metadata). This then causes the
free-after-use bug described in #163.
This patch fixes the order in which we destruct objects and related
sd-event-sources. Some open questions remain:
* Why does source_io_unregister() not warn on EPOLL_CTL_DEL failures?
This really needs to be turned into an assert_return().
* udevd really should not leak file-descriptors into its children. Fixing
this would *not* have prevented this bug, though (since the child-setup
is still async).
It's non-trivial to fix this, though. The stack-context of the caller
cannot be rewinded, so we cannot figure out temporary refs. Maybe it's
time to exec() the udev-workers?
* Why does the kernel not copy FD-subscriptions across fork()?
Or at least drop subscriptions if you close() your FD (it uses the
FD-number as key, so it better subscribe to it)?
Or it better used
FD+"struct file_table*"+"struct file*"
as key to not allow the childen to share the subscription table..
*sigh*
Seems like we have to live with that API forever.
Currently, the HASHMAP iterators stop at the first NULL entry in a
hashmap. This is non-obvious and breaks users like sd-device, which
legitimately store NULL values in a hashmap.
Fix all the iterators by taking a pointer to the value storage, instead of
returning it. The iterators now return a boolean that tells whether the
end of the list was reached.
Current users of HASHMAP_FOREACH() are *NOT* changed to explicitly check
for NULL. If it turns out, there were users that inserted NULL into
hashmaps, but didn't properly check for it during iteration, then we
really want to find those and fix them.
If you use bus_map_all_properties(), you must be aware that it might
touch output variables even though it may fail. This is, because we parse
many different bus-properties and cannot tell how to clean them up, in
case we fail deep down in the parser.
Fix all callers of bus_map_all_properties() to correctly cleanup any
context structures at all times.
We do not support '/run' for hwdb files. Drop it from the man-pages so
people don't accidentally use it.
This was reported by: Peter Hutterer <peter.hutterer@who-t.net>
DBus-spec defines two different pattern matchings:
1) Path and namespace prefix matching. In this case, A matches B either
if both are equal, or if B is fully included in the namespace of A.
In other words, A has to be a prefix of B, but end with a separator
character (or the following character in B must be one).
This is used for path_namespace= and arg0namespace=
2) The other pattern matching is used for arg0path= which does a two-way
matching. That is, A must be a prefix of B, or B a prefix of A.
Furthermore, the prefix must end with a separator.
Fix the sd-bus helpers to reflect that. The 'simple_' and 'complex_'
prefixes don't make any sense now, but.. eh..
Make sure we actually verify our match-rules are executed properly. Right
now all we test is the bloom-matches, which are non-reliable as they leave
through false-positives.
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.
Lets look at an example where we add arg0="/foo/bar/waldo" to a
bloom-filter. The following strings are added:
"arg0:/foo/bar/waldo"
"arg0-slash-prefix:/foo/bar"
"arg0-slash-prefix:/foo"
Two problems arise:
1) If we match on "arg0path=/foo/bar/waldo", the dbus-spec explicitly
states that equal strings are also considered prefixes. However, in the
bloom-match, we can only provide a single match-filter. Therefore, we have
to add "arg0-slash-prefix:/foo/bar/waldo" there, but this never occured in
the bloom-mask of the message.
Hence, this patch makes sure bloom_add_prefixes() adds the full path as
prefix, too.
2) If we match on "arg0path=/foo/", the dbus-spec states that arg0path
does prefix-matching with the trailing slash _included_, unlike
path_namespace= matches, which does *not* include them. This is
inconsistent, but we have to support the specs. Therefore, we must add
prefixes with _and_ without trailing separators.
Hence, this patch makes sure bloom_add_prefixes() adds all prefixes with
the trailing slash included.
The final set of strings added therefore is:
"arg0:/foo/bar/waldo"
"arg0-slash-prefix:/foo/bar/waldo"
"arg0-slash-prefix:/foo/bar/"
"arg0-slash-prefix:/foo/bar"
"arg0-slash-prefix:/foo/"
"arg0-slash-prefix:/foo"
"arg0-slash-prefix:/"
Right now we always pass KDBUS_ITEM_ATTACH_FLAGS_RECV to
KDBUS_CMD_BUS_MAKE, effectively forcing every bus connection to do the
same during KDBUS_CMD_HELLO. This used to be a workaround to make sure all
metadata is always present. However, we refrained from that approach and
intend to make all metadata collection solely rely on /proc access
restrictions. Therefore, there is no need to force the send-flags mask on
newly created buses.
This partly reverts:
commit 6d1b1e0bc6
Author: Tom Gundersen <teg@jklm.no>
Date: Sun May 24 15:10:04 2015 +0200
udevd: worker - fully clean up unnecessary fds
The inotify-fd _is_ used in the workers, so don't close it! Have a look at
udev-watch.c, which keeps track of the inotify-fd as a global variable
(ugh!).
Whenever systemd is re-executed, it tries to create a system bus via
kdbus. If the system did not have kdbus loaded during bootup, but the
module is loaded later on manually, this will cause two system buses
running (kdbus and dbus-daemon in parallel).
This patch makes sure we never try to create kdbus buses if it wasn't
explicitly requested on the command-line.
Boolean arithmetic is great, use it!
if (a && !b)
return 1;
if (!a && b)
return -1,
is equivalent to
if (a != b)
return a - b;
Furthermore:
r = false;
if (condition)
r = true;
is equivalent to:
r = condition;
Whenever we provide a bus API that allows clients to create and manage
server-side objects, we need to provide a unique name for these objects.
There are two ways to provide them:
1) Let the server choose a name and return it as method reply.
2) Let the client pass its name of choice in the method arguments.
The first method is the easiest one to implement. However, it suffers from
a race condition: If a client creates an object asynchronously, it cannot
destroy that object until it received the method reply. It cannot know the
name of the new object, thus, it cannot destroy it. Furthermore, this
method enforces a round-trip. If the client _depends_ on the method call
to succeed (eg., it would close() the connection if it failed), the client
usually has no reason to wait for the method reply. Instead, the client
can immediately schedule further method calls on the newly created object
(in case the API guarantees in-order method-call handling).
The second method fixes both problems: The client passes an object name
with the method-call. The server uses it to create the object. Therefore,
the client can schedule object destruction even if the object-creation
hasn't finished, yet (again, requiring in-order method-call handling).
Furthermore, the client can schedule further method calls on the newly
created object, before the constructor returned.
There're two problems to solve, though:
1) Object names are usually defined via dbus object paths, which are
usually globally namespaced. Therefore, multiple clients must be able
to choose unique object names without interference.
2) If multiple libraries share the same bus connection, they must be
able to choose unique object names without interference.
The first problem is solved easily by prefixing a name with the
unique-bus-name of a connection. The server side must enforce this and
reject any other name.
The second problem is solved by providing unique suffixes from within
sd-bus. As long as sd-bus always returns a fresh new ID, if requested,
multiple libraries will never interfere. This implementation re-uses
bus->cookie as ID generator, which already provides unique IDs for each
bus connection.
This patch introduces two new helpers:
bus_path_encode_unique(sd_bus *bus,
const char *prefix,
const char *sender_id,
const char *external_id,
char **ret_path);
This creates a new object-path via the template
'/prefix/sender_id/external_id'. That is, it appends two new labels to
the given prefix. If 'sender_id' is NULL, it will use
bus->unique_name, if 'external_id' is NULL, it will allocate a fresh,
unique cookie from bus->cookie.
bus_path_decode_unique(const char *path,
const char *prefix,
char **ret_sender,
char **ret_external);
This reverses what bus_path_encode_unique() did. It parses 'path' from
the template '/prefix/sender/external' and returns both suffix-labels
in 'ret_sender' and 'ret_external'. In case the template does not
match, 0 is returned and both output arguments are set to NULL.
Otherwise, 1 is returned and the output arguments contain the decoded
labels.
Note: Client-side allocated IDs are inspired by the Wayland protocol
(which itself was inspired by X11). Wayland uses those IDs heavily
to avoid round-trips. Clients can create server-side objects and
send method calls without any round-trip and waiting for any object
IDs to be returned. But unlike Wayland, DBus uses gobally namespaced
object names. Therefore, we have to add the extra step by adding the
unique-name of the bus connection.
This is like bus_label_unescape() but takes a maximum length instead of
relying on NULL-terminated strings. This is highly useful to unescape
labels that are not at the end of a path.
We _always_ return NULL from destructors to allow direct assignments to
the variable holding the object. Especially on hashmaps, which treat NULL
as empty hashmap, this is pretty neat.
The macros in shared/macro.h have been updated to no longer use fixed
variable names. This will silence any shadowing-warnings, so drop the
DISABLE_WARNING_* annotations.
Avoid unbound for(;;) loop and use the established coding-style:
while ((r = sd_bus_message_read*(...)) > 0) {
}
if (r < 0)
return r;
This is much easier to read and used all over the code base.
We must not fail on ENOENT. We properly create the mount-point in
mount-setup, so there's really no reason to skip the mount. Make sure we
just skip the mount on unexpected failures or if it's already mounted.
We should never access parents, as the sysfs hierarchy is in no way
stable. Use KERNELS== etc. to match on a parent, then access it via
$attr{} (which accesses the matching device, not the current device).
We match on the evdev node, but only the parent has a "name" attribute.
Use $attr{device/name} to access it.
This is borked since 2013, I wonder how that ever worked? Maybe this will
suddenly fix all the DMI-based key detections.
Thanks to Peter Hutterer for catching this!
This reverts commit ba76ee29bc. As it turns
out, we need to match on driver=atkbd to not load the fixups on any
plugged USB devices.
That is, whenever you use "name:<name>:dmi:<dmi>" style matches, you
better provide a name or you're screwing things up.
Currently, we always run
hwdb 'keyboard:name:$attr{name}:$attr{[dmi/id]modalias}'
as last step to match keyboards. Therefore, if nothing else matched so
far, we still try the device-name+dmi combination.
However, we have a special atkbd rule which is only run for atkbd as:
hwdb 'keyboard:$attr{[dmi/id]modalias}'
This is redundant, as we already pass the same information to hwdb in the
last fallback step.
This patch converts the hwdb "keyboard:dmi:*" matches to
"keyboard:name:*:dmi:*" matches and drops the redundant rule.
There is no reason to match on usb-modaliases, if we can use the
input-modalias to achieve the same. This commit changes the
keyboard-lookups to not be restricted to USB, but pass all modaliases to
the hwdb. Furthermore, we convert all usb:* matches to input:* matches,
thus getting rid of any ambiguity if multiple usb devices are chained (or
a bluetooth device / etc. is on top).
Note that legacy keyboard:usb:* matches are still supported, but
deprecated. If possible, please use keyboard:input:* matches instead.
This is a required step to make other input devices work with
60-keyboard.hwdb. Other bus-types are often chained on usb and we want to
avoid any ambiguity here if we incorrectly match on a USB hub.
The error code is called EDEADLK, stop using legacy names like EDEADLOCK.
Note that _some_ weird architectures define them differently (namely, mips
and sparc), but on all sane architectures they're exactly the same. So
stay with the widely used code, which is EDEADLK.
On kdbus, we get cgroups-agent messages via the system bus, not the
private systemd socket. Therefore, we must install the match properly or
we will never receive cgroup notifications.
Forwarding messages that are not rewinded will drop data. Fix this for
cgroups-agent messages that we might remarshal before forwarding to the
system bus.
If we receive an sd_bus_message from the kernel, m->kdbus will contain
additional items that cannot be used when sending a message. Therefore,
always remarshal the message if it is used again.
If the local peer does not dispatch its incoming queue, the bus-proxy will
slowly fill its outgoing queue. Once its full, it will continously
complain that it cannot forward its messages.
As it turns out, pulseaudio does have an idle background dbus connection
that is not integrated into any mainloop (and given that gdbus and
libdbus1 both support background shared connections, PA is probably not
the only example), therefore, the bus-proxy will loudly complain if it
cannot forward NameOwnerChanged events once the queue is full.
This commit makes the proxy track queue-state and complain only once the
queue runs full, not if it is already full.
A PA bug-report (and patch) has been filed, and other applications should
be fixed similarly. Hence, lets keep the error message, instead of
dropping it. It's unused resources we really want to get rid of, so
silencing the message does not really help (which is actually what
dbus-daemon does).
This introduces a new SYSVIEW_EVENT_SETTLE notification that is sent after
initial scanning via sysview is done. This is very handy to let the
application raise warnings in case requested resources are not found
during startup.
The SETTLE event is sent after systemd-logind and udev enumerations are
done. This event does in no way guarantee that a given resource is
available. All it does is notify the application that scanning is done!
You must not react to SETTLE if you don't have external synchronization
with the resource you're waiting for.
The main use-case for SETTLE is to run applications _inside_ of logind
sessions and startup sysview. You really want to make sure that the own
session you're running in was found during enumeration. If not, something
is seriously wrong.
The error-code propagated via sysview is always negative. Avoid
multiplying by -1 before returning it. Otherwise, we will return >0
instead of <0, which will not be detected as error by sysview-core.
This introduces 'HoldoffTimeoutSec' to logind.conf to make
IGNORE_LID_SWITCH_{SUSPEND,STARTUP}_USEC configurable.
Background: If an external monitor is connected, or if the system is
docked, we want to ignore LID events. This is required to support setups
where a laptop is used with external peripherals while the LID is closed.
However, this requires us to probe all hot-plugged devices before reacting
to LID events. But with modern buses like USB, the standards do not impose
any timeout on the slots, so we have no chance to know whether a given
slot is used or not. Hence, after resume and startup, we have to wait a
fixed timeout to give the kernel a chance to probe devices. Our timeout
has always been generous enough to support even the slowest devices.
However, a lot of people didn't use these features and wanted to disable
the hold-off timer. Now we provide a knob to do that.
gcc does not support testing for negated warnings. See here for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63499
This patch changes CC_CHECK_FLAG_APPEND to always test for the non-negated
warnings.
gcc5 introduced this option (gcc4 silently ignores it, which is fine).
Given that gcc5 thinks 'unsigned char'/'unsigned short' is promoted to
'int' for var-args, stuff like this spits out warnings:
uint8_t x;
printf("%" PRIu8", x);
gcc5 promots 'x' to 'int', instead of 'unsigned int' and thus gets a
signedness-warnings as it expects an 'unsigned int'.
glibc states otherwise: unsigneds are always promoted to 'unsigned int'.
Until gcc and glibc figure this out, lets just ignore that warning (which
is totally useless in its current form).
If we cannot forward messages, include information on the peer and message
just like the xml-policy does. This helps debugging such situations and
figuring out what exactly is going wrong.
'LinkLocal' was renamed to 'LinkLocalAddressing' in:
commit 56fd6bf795
Author: Tom Gundersen <teg@jklm.no>
Date: Sat Feb 14 00:32:26 2015 +0100
networkd: .network - rename LinkLocal to LinkLocalAddressing
..but apparently the network files were not updated. Fix this.
UDS sockets transmit EUID+EGID only. Don't try to fake data we don't know!
Otherwise, this might be used to override user-limits by non-root setuid
programs (by faking UID==EUID).
Now that sd-bus is fixed to always use EUID even on UDS, we can safely set
all other UID/GID fields to INVALID.
There is no reason to provide our own attach_flags_mask. We can simply
rely on kdbus.attach_flags_mask= which is read by the kernel *and* kmod.
If it's set, we assume the user wants to override our setting, so we
simply skip setting it.
The kernel module system is not namespaced, so no container should ever
modify global options. Make sure we set the kdbus attach_flags_mask only
on a real boot as PID1.
While it's a lovely scenario, it's probably not really useful. Fix our
GetConnectionUnixUser() to return the actual 'euid' which we asked for,
not the possible uninitialized 'uid'.
This reverts commit 68e68ca810. We *need*
root access to create cgroups. The only exception is if it is run from
within a cgroup with "Delegate=yes". However, this is not always true and
we really shouldn't rely on this.
If your terminal runs from within a systemd --user instance, you're fine.
Everyone else is not (like running from ssh, VTs, and so on..).
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.
Make sure we tell the kernel to fake all UIDs/GIDs. Otherwise, the remote
side has no chance of querying our effective UID (which is usually what
they're interested in).
We need to implicitly allow HELLO from users with the same uid as the bus.
Fix the bus-uid tracking to use the original uid, not the uid after
privilege-dropping.
If the caller does not run in a session/seat or has no tracked user, hide
the /org/freedesktop/login1/.../self links in introspection data.
Otherwise, "busctl tree org.freedesktop.login1" tries to query those nodes
even though it cant.
If we test the policy against multiple destination names, we really should
not print warnings if one of the names results in DENY. Instead, pass the
whole array of names to the policy and let it deal with it.
We cannot use "User=" in unit-files if we want to retain privileges. So
make bus-proxy.c explicitly drop privileges. However, only do that if
we're root, as there is no need to drop it on the user-bus.
This implements a shared policy cache with read-write locks. We no longer
parse the XML policy in each thread.
This will allow us to easily implement ReloadConfig().
Set thread-names to "p$PIDu$UID" and suffix with '*' if truncated. This
helps debugging bus-proxy issues if we want to figure out which
connections are currently open.
Instead of using Accept=true and running one proxy for each connection, we
now run one proxy-daemon with a thread per connection. This will enable us
to share resources like policies in the future.
Move all the proxy code into a "struct Proxy" object that can be used
from multiple binaries.
We now dropped SMACK as we have to refactor it to work properly. We can
introduce it later on.
The 'at_console' policy-category allows to apply policy-items to clients
depending on whether they're run from within a valid user-session or not.
We use sd_uid_get_seats() to check whether a user has a valid seat (which
excludes remote-sessions like ssh).
If a dbus-1 client sends a broadcasted signal via the bus-proxy to kdbus,
the bus-proxy has no idea who the receiver is. Classic dbus-daemon has
bus-access and can perform policy checks for each receiver, but we cant.
Instead, we know the kernel will perform receiver policy checks for
broadcasts, so we can skip the policy check and just push it into the
kernel.
This fixes wpa_supplicant which has DENY rules on receive_type=signal for
non-root. As we never know the target, we always DENY all broadcasts from
wpa_supplicant.
Note that will still perform receiver-policy checks for signals that we
get from the kernel back to us. In those cases, we know the receiver
(which is us).
dbus-1 distinguishes expected and non-expected replies. An expected reply
is a reply that is sent as answer to a previously forwarded method-call
before the timeout fires. Those replies are, by default, forwarded and
DENY policy tags are ignored on them (unless explicitly stated otherwise).
We don't track reply-windows in the bus-proxy as the kernel already does
this. Furthermore, the kernel prohibits any non-expected replies (which
breaks dbus-1, but it was an odd feature, anyway).
Therefore, skip policy checks on replies and always let the kernel deal
with it!
To be correct, we should still process DENY tags marked as
send_expected_reply=true (which is *NOT* the default!). However, so far we
don't parse those attributes, and no-one really uses it, so lets not
implement it for now. It's marked as TODO if anyone feels like fixing it.
Make sure to extract the log-priority when comparing against
max-log-level, otherwise, we will always drop those messages.
This fixes bus-proxyd to properly send warnings on policy blocks.
Imagine a kdbus peer sending a method-call without EXPECT_REPLY set
through the proxy to a dbus1 peer. The proxy turns the missing
EXPECT_REPLY flag into a dbus1 NO_REPLY_EXPECTED flag. However, if the
receipient ignores that flag (valid dbus1 behavior) and sends a reply, the
proxy will try to forward it to the original peer. This will fail with
EPERM as the kernel didn't track the reply.
We have two options now: Either we ignore EPERM for reply messages, or we
track reply-windows in the proxy so we can properly ignore replies if
EXPECT_REPLY wasn't set.
This commit chose the first option: ignore EPERM for replies. The only
down-side is that replies without matching method call will no longer be
forwarded by the proxy. This works on dbus1, though.
Nobody sane does this, so lets ignore it.
If a caller does not request a reply, dont send it. This skips message
creation and speeds up NO_REPLY_EXPECTED cases. Note that sd-bus still
handles this case internally, but if we handle it in bus-proxyd, we can
skip the whole message creation step.
dbus1 does not provide cmdline, so we have to augment our credentials from
/proc to beautify the bus-proxyd cmdline. We dont use this for anything
but beautification, so there shouldn't be any problems due to /proc
pid-recycling races.
This fixes bus-proxyd to no longer display 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
in its cmdline.
David Herrmann