| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#31715)
This adds for both the D-Bus and the Varlink flavours of our polkit
client api a flags parameter. And then folds the "bool interactive" flag
that the D-Bus version so far had, into a flag, and also adds support
for it in the Varlink API.
Since this means the Varlink API gained another parameter, let's do what
we already did for the D-Bus API and add a _full() version of the API
that has the flags and the good_uid parameter, and one without both.
|
| |
|
| |
|
|
|
|
|
|
| |
For the very similar case of the product UUID we have its own error
BUS_ERROR_NO_PRODUCT_UUID if we have no UUID. Let's mirror this for the
hardware serial, and expose the same, to keep things nicely symmteric.
|
|
|
|
|
|
| |
Let's make sure the serial contains not control chars, and is UTF-8
clean. In particular the latter matters as D-Bus shouldn't kick us
from the bus.
|
|
|
|
| |
return it
|
|
|
|
| |
No idea what was going on here...
|
|
|
|
|
|
|
|
|
|
| |
There's some appetite to have the full os-release/machine-info data
exposed by hostnamed.
let's do so in the Describe() method and via Varlink. It's trivial after
all.
Inspired by: #18649
|
| |
|
|
|
|
|
|
|
|
|
| |
that way clients can distinguish whether there is no cid or whether
hostnamed doesn't support it nicely, by just looking if the prop exists
(but is null) or not.
This is similar how we already handle all other props in the JSON
record.
|
| |
|
|
|
|
|
| |
It's a bit weird to keep this separate in particular as the polkit
object is already part of the context.
|
| |
|
|
|
|
|
| |
This is a host identifier of major relevance, since it is how you
connect to this system if it is a VM, hence expose this nicely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies bus_verify_polkit_async() and related calls quite a bit:
1. This removes any support for authentication-by-Linux-capability. This
is ultimately a kdbus leftover: with classic AF_UNIX transports we
cannot authenticate by capabilities securely (because we cannot
acquire it from the peer without races), hence we never actually did.
Since the necessary kernel work didn't materialize in the last 10y,
and is unlikely to be added, let's just kill this context. We cannot
quite remove the caps stuff from sd-bus for API compat, but for our
polkit logic let's kill it.
2. The "good_uid" and "interactive" params are only necessary in very
few cases, hence let's move them to a new call
bus_verify_polkit_async_full() and make bus_verify_polkit_async() a
wrapper around it without those two parameters.
This also fixes a bunch of wrong uses of the "interactive" bool. The
bool makes no sense today as the ALLOW_INTERACTIVE_AUTHORIZATION field
in the D-Bus message header replaces it fully. We only need it to
implement method calls we introduced prior to that header field becoming
available in D-Bus. And it should only be used on such old method calls,
and otherwise always be set to false.
This does not change behaviour in any way. Just simplifies stuff.
Fixes: #21586
|
|
|
|
| |
Fixes #30293.
|
|
|
|
|
|
|
| |
This also makes write_env_file() and write_env_file_label() optionally
take dir_fd, and drop write_env_file_at().
Preparation for later commits.
|
|
|
|
| |
Fixes #28943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
safe_atou() by default determines the base from the prefix 0x, 0b, 0o
and for compat with just 0 for octal. This is not what we want here,
since the date components are padded with zeroes yet still decimal.
Hence force decimal parsing (and while we are at it, prohibit a couple
of unexpected decorations).
WIthout this we'd fail to parse any the 8th and 9th day of each months, as
well aus aug and september of every year, because these look like octal
numbers but cannot actually parsed as such.
Let's change the testcase to check for a date that exposes this
bheaviour.
|
|
|
|
|
| |
If we run in a container we should show info about the container, not
the host.
|
|
|
|
|
|
|
|
|
| |
By default, label_ops is initialized with a NULL pointer which translates
to noop labelling operations. In mac_selinux_init() and the new mac_smack_init(),
we initialize label_ops with a MAC specific LabelOps pointer.
We also introduce mac_init() to initialize any configured MACs and replace all
usages of mac_selinux_init() with mac_init().
|
| |
|
| |
|
|
|
|
|
|
| |
Offer the firmware date as an epoch instead of the literal DMI string.
Closes #25679
|
|
|
|
| |
Expose /sys/class/dmi/id/bios_date as dbus property in hostnamed.
|
|
|
|
| |
Expose /sys/class/dmi/id/bios_vendor as dbus property in hostnamed.
|
|
|
|
|
|
| |
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
|
|
|
|
|
| |
util.h is now about logarithms only, so we can rename it. Many files included
util.h for no apparent reason… Those includes are dropped.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases we refernced the concept as "initrd". Let's convert most
remaining uses of "initramfs" to "initrd" too, to stay internally
consistent.
This leaves "initramfs" only where it's relevant to explain historical
concepts or where "initramfs" is part of the API (i.e. in
/run/initramfs).
Follow-up for: b66a6e1a5838b874b789820c090dd6850cf10513
|
| |
|
|
|
|
|
|
| |
Fixes a bug introduced by 8c8b1800e90d4307397300ef32b0f6d95efad057.
Fixes #24384.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
These days we have a mechanism for safely returning errnos in enum
types, via definining -ERRNO_MAX as one special enu value. Let's use
that for Virtualization.
No change in behaviour, just some typesafety improvement.
|
| |
|
|
|
|
| |
Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's be more precise here. Otherwise people might think this describes
the software system or so. We already expose this via hostnamed as
HardwareVendor/HardwareModel hence use the exact same wording.
(Note that the relevant props on the dmi device are just VENDOR/MODEL,
but that's OK given that DMI really is about hardware anyway,
unconditionally, hence no chance of confusion there.)
Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since a long time the D-Bus spec knows a special bit in its message
header for indicating that "interactive" authentication is OK. The
original hostnamed API is before that was added hence most functions
expose that boolean as explicit argument.
For new added functions let's get rid of it, the message flag is good
enough and replaces it with complete functionality.
No new APIs should carry the "interactive" boolean flag explicitly as
argument anymore.
Follow-up for: 9697662915e47a4797b05003cb1970fe2b01e530
|
|
|
|
| |
Closes #22119.
|
|
|
|
|
|
|
|
|
|
| |
Sometimes hardware vendor does not set DMI info correctly.
Already there is a way that the dbus properties can be overriden by
using hwdb. But that is not user friendly.
This adds two new fields in /etc/machine-info.
Closes #22207.
|
|
|
|
| |
Follow-up for 4b35eb2579b226785f0d94129a7652450f9723fd.
|
|
|
|
| |
Closes: #7390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
From https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-ofw
---
Userspace must not use the /sys/firmware/devicetree/base
path directly, but instead should follow /proc/device-tree
symlink. It is possible that the absolute path will change
in the future, but the symlink is the stable ABI.
---
Addresses the comment https://github.com/systemd/systemd/pull/20731#discussion_r744095262.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Device-tree based devices can't get the chassis type from DMI or ACPI,
and so far need a custom `/etc/machine-info` to set this property right.
A new 'chassis-type' toplevel device tree property has recently been
approved into the DT specification, making it possible to automate
chassis type detection on such devices.
This patch therefore falls back to reading this device-tree property if
nothing is available through both DMI and ACPI.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
|
|
|
|
| |
variants
|