refactor to use timerfd in place of rtc wakealarm
confirm CLOCK_BOOTTIME_ALARM support in can_s2h
Remove CLOCK_BOOTTIME_ALARM task from TODO
remove unnecessary check on clock_supported return
LUKS2 supports so-called tokens. The libcryptsetup internally
support keyring token (it tries to open device using specified
keyring entry).
Only if all token fails (or are not available), it uses a passphrase.
This patch aligns the functionality with the cryptsetup utility
(cryptsetup luksOpen tries tokens first) but does not replace
the systemd native ask-password function (can be used the same in
combination with this patch).
The crypt_load() for LUKS2 can read a quite big area of disk
(metadata area size is configurable and can increase up to megabytes).
This initialization is not needed to be repeated, just use the existing context.
(This patch is also required for the following change.)
If crypt_load() for LUKS succeeds, we know that it is a LUKS device.
Failure of data device setting should fail in this case; remapping
as a PLAIN device late could mean data corruption.
(If a user wants to map PLAIN device over a device with LUKS header,
it should be said explicitly with "plain" argument type.)
Also, if there is no explicit PLAIN type requested and crypt device
is already initialized (crypt_data_type() is set), do not run
the initialization again.
This suppress the following warning:
```
systemd-udevd[437]: Config file /usr/lib/systemd/network/99-default.link
applies to device based on potentially unpredictable interface name 'wlan0'
```
Follow-up for 84ea567eb4.
Only changing ownership back to root is not enough we also need to
change the access mode, otherwise the user might have set 666 first, and
thus allow everyone access before and after the chown().
Inspired by #12431 let's also rework chmod_and_chown() and make sure we
never add more rights to a file not owned by the right user.
Also, let's make chmod_and_chown() just a wrapper arond
fchmod_and_chown().
let's also change strategy: instead of chown()ing first and stating
after on failure and supressing errors, let's avoid the chown in the
firts place, in the interest on keeping things minimal.
Previously, logind's logind-session.h would define prototypes for
logind-session.c and logind-session-dbus.c. Split that out, so that
there's a separate logind-session-dbus.h for that. Similar for seats and
users as well as the manager itself.
This changes no code, just rearranges where protoypes are located.
Most of the operations one can do on sessions so far accepted an empty
session name as a shortcut for the caller's session. This is quite
useful traditionally, but much less useful than it used to be, since
most user code now (rightfully) runs in --user context, not in a
session.
With this change we tweak the logic a bit: we introduce the two special
session and seat names "self" and "auto". The former refers to the
session/seat the client is in, and is hence mostly equivalent to te
empty string "" as before. However, the latter refers to the
session/seat the client is in if that exists, with a fallback of the
user's display session if not. Clients can hence reference "auto"
instead of the empty string if they really don't want to think much
about sessions.
Why "self" btw? Previously, we'd already expose a special dbus object
with the path /org/freedesktop/login1/session/self (and similar for the
seat), matching what the empty string did for bus calls that took a
session name. With this scheme we reuse this identifier and introduce
"auto" in a similar way.
Of course this means real-life seats and sessions can never be named
"self" or "auto", but they aren't anyway: valid seat names have to start
with "seat" anyway, and sessions are generated server-side as either a
numeric value or "c" suffixed with a counter ID.
Fixes: #12399
Interestingly, elect_display_compare() already ordered "user" sessions
before "greeter" sessions, though nothing other than "user" sessions
where ever considered anyway.
Fixes: #12399
This augments the drm/input device management by adding a single method
call for setting the brightness of an "leds" or "backlight" kernel class
device.
This method call requires no privileges to call, but a caller can only
change the brightness on sessions that are currently active, and they
must own the session.
This does not do enumeration of such class devices, feature or range
probing, chnage notification; it doesn't help associating graphics or
input devices with their backlight or leds devices. For all that clients
should go directly to udev/sysfs. The SetBrightness() call is just for
executing the actual change operation, that is otherwise privileged.
Example line:
busctl call org.freedesktop.login1 /org/freedesktop/login1/session/self org.freedesktop.login1.Session SetBrightness ssu "backlight" "intel_backlight" 200
The parameter the SetBrightness() call takes are the kernel subsystem
(i.e. "leds" or "backlight"), the device name, and the brightness
value.
On some hw setting the brightness is slow, and implementation and write
access to the sysfs knobs exposes this slowness. Due to this we'll fork
off a writer process in the background so that logind doesn't have to
block. Moreover, write requestes are coalesced: when a write request is
enqueued while one is already being executed it is queued. When another
write reques is then enqueued the earlier one is replaced by the newer
one, so that only one queued write request per device remains at any
time. Method replies are sent as soon as the first write request that
happens after the request was received is completed.
It is recommended that bus clients turn off the "expect_reply" flag on
the dbus messages they send though, that relieves logind from sending
completion notification and is particularly a good idea if clients
implement reactive UI sliders that send a quick secession of write
requests.
Replaces: #12413
These devices do not become user-accessible this way, but they are
logically assigned to a seat, which makes a lot of sense, since they are
human-facing output devices, and such should belong to one.
Depending on system configuration and whether SCMP_ACT_KILL_PROCESS or
SCMP_ACT_KILL_THREAD is available/used processes might coredump on
specific coredumps or are just plain killed. For our test case the
difference doesn't really matter, hence let's hide it away.
Yu Watanabe
Zach Smith
Lennart Poettering
Milan Broz
Zbigniew Jędrzejewski-Szmek