| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
imply calling session/user instead
This turns "lock-session", "activate", "unlock-session",
"enable-linger", "disable-linger" into commands that take no argument,
optionally in which case the callers session/user is implied.
|
|
needlessly send it if we don't actually need it
|
|
|
|
|
|
|
|
|
|
to the bus owner should be allowed
Hence, copy this behaviour for bus-proxy too.
|
|
|
|
|
|
|
|
determine them from the caller credentials
More specifically, if an operation is requested on a session with an
empty name, the caller's session is used. If an operation is requested
on a seat with an empty name, the seat of the caller's session is used.
Finally, if an operation on the user with UID -1 is requested, the user
of the client's session is used (and not the UID of the client!).
|
|
|
|
Makes "busctl introspect" a lot more fun.
|
|
caller's session status
Similar for user-status and seat-status.
|
|
Among other things, avoid log_struct() unless we really need it.
Also, use "r" as variable to store function errors in, instead of "err".
"r" is pretty much what we use everywhere else, hence using the same
here make sense.
FInally, in the child, when we want to log, make sure to open the
logging framework first, since it is explicitly closed in preparation
for the exec().
|
|
Now that we bump rlimit, we do not really know how many files
we can open. Remove the check.
https://bugzilla.redhat.com/show_bug.cgi?id=1179980
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=88216
|
|
Make sure to append bloom-filters to all signal-messages, not only
broadcasts.
|
|
Error, DATA expected but got 'mouse:usb:v046dpc24c:name:Logitech G400s Optical
Gaming Mouse:' in '/etc/udev/hwdb.d/70-mouse.hwdb':
Error, MATCH expected but got ' MOUSE_DPI=400@1000 *800@1000 2000@1000
4000@1000' in '/etc/udev/hwdb.d/70-mouse.hwdb':
Introduced in 6366e349
|
|
|
|
|
|
non-fatal
This should be useful for user namespaces.
|
|
|
|
The tool is badly maintained and we shouldn't refence such old cruft.
|
|
|
|
|
|
|
|
|
|
|
|
methods, start the polkit agent on terminals
|
|
|
|
user-status" and "loginctl session-status"
|
|
Devices with dynamic frequency scaling adjust the frequency as needed. For
those we only care about the maximum frequency, not the various in betweens.
https://bugs.freedesktop.org/show_bug.cgi?id=87435#c8
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=87435
|
|
*Autocompletion for dirs, doesn't leave until you press space.
*Added tmpfs, volatile and network-macvlan options.
I tried with the SELinux options with seinfo(setools-console), but too
messy to get it right. Even Daniel Walsh haven't done it yet. :)
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=66396
|
|
|
|
This was subsumed into systemd-analyze back in 142c4ecaa98.
|
|
man machine-info lacks hostnamed chassis type "embedded" as introduced in 218. The following lines should fix this.
|
|
|
|
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.
|
|
|
