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.
These services are likely to coredump, and we expect that but aren't
interested in the coredump. Hence let's turn off processing by setting
RLIMIT_CORE to 0/0.
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.
This text was written a long time ago, when we mostly talked about "service
files". Strictly speaking, we don't need a "file", because the service might
be just an instance of a template, or an alias to another service. So let's use
the more modern parlance of "service units".
https://bugzilla.redhat.com/show_bug.cgi?id=1623781#c21
I covered the most obvious paths: those where there's a clear problem
with a path specified by the user.
Prints something like this (at error level):
May 21 20:00:01.040418 systemd[125871]: bad-workdir.service: Failed to set up mount namespacing: /run/systemd/unit-root/etc/tomcat9/Catalina: No such file or directory
May 21 20:00:01.040456 systemd[125871]: bad-workdir.service: Failed at step NAMESPACE spawning /bin/true: No such file or directory
Fixes#10972.
Lennart Poettering