The problem with the original form is that the subject of the sentence with
passive void is "the system", and we're not inhibiting the system. In English
the sense can be made out, but the form is gramatically incorrect.
In fact, the Polish translation got this wrong:
> msgid "Power off the system while an application is inhibiting this"
> msgstr "Wyłączenie systemu, kiedy program zażądał jego wstrzymania"
"jego" can only refer to "the system", because of gender mismatch with "power
off". If our translators cannot grok the message, then we should probably reword
it.
Also, drop the "asked to" part. Everything we do is over IPC, so we only ever
"ask" for things, and this adds no value.
Rely on information provided by /proc/*/stat and /sys/dev/char for resolving
the controlling tty for the display server, instead of trying to access the
tty device in /dev (which may not be accessible for example due to
PrivateDevices=yes).
Let's lock this down a bit. Effectively nothing much changes, since the
default PK policy will allow users on the VT to change VT. Only users
with no local VT session won't be able to switch VTs.
Previously we'd allow marking TTY sessions as idle, but when the user
tried to unmark it as idle again it we'd just revert to automatic TTY
atime idle detection, thus making it impossible to mark the session as
non-idle, unless its TTY is atime-touched all the time. But of course,
marking a session as idle is pretty much fatal if you never can mark it
as non-idle again.
This change is triggred by bug reports such as this:
https://github.com/systemd/systemd/issues/14053
With this patch we will now output a clean, clear error message if a
client tries to manipulate the idle state of a non-graphical session.
This means we now have clear rules: "manual" idle logic for graphical
sessions, and TTY based ones for all others that have a TTY of some
form.
I considered allowing the idle state to be overriden both ways for tty
sessions but that's problematic: for sessions that are temporarily
upgraded from tty to graphical and thus suddenly want to manage their
own idle state we'd need to a way to detect when the upgrade goes away
and thus we should revert to old behaviour. Without reverting to the
previous TTY idle auto-magic we'd otherwise be stuck in an eternally
idle or eternally non-idle state, with really bad effects in case
auto-suspend is used. Thus, let's instead generate a proper error
message, saying clearly we don't support it.
(Also includes some other fixes and clean-ups in related code)
Closes: #14053
To support ProtectHome=y in a user namespace (which mounts the inaccessible
nodes), the nodes need to be accessible by the user. Create these paths and
devices in the user runtime directory so they can be used later if needed.
It's not really clear which PAM errors to use for which conditions, but
something called PAM_SYSTEM_ERR should probably not be used when the
error is not the result of some system call failure.
This cleans up and unifies the outut of --help texts a bit:
1. Highlight the human friendly description string, not the command
line via ANSI sequences. Previously both this description string and
the brief command line summary was marked with the same ANSI
highlight sequence, but given we auto-page to less and less does not
honour multi-line highlights only the command line summary was
affectively highlighted. Rationale: for highlighting the description
instead of the command line: the command line summary is relatively
boring, and mostly the same for out tools, the description on the
other hand is pregnant, important and captions the whole thing and
hence deserves highlighting.
2. Always suffix "Options" with ":" in the help text
3. Rename "Flags" → "Options" in one case
4. Move commands to the top in a few cases
5. add coloring to many more help pages
6. Unify on COMMAND instead of {COMMAND} in the command line summary.
Some tools did it one way, others the other way. I am not sure what
precisely {} is supposed to mean, that uppercasing doesn't, hence
let's simplify and stick to the {}-less syntax
And minor other tweaks.
We would only write to the field, and take the address. All *readers* were
removed in 2841493927. (The explanation for why
the field wasn't removed back then is that the patch underwent a few iterations,
with the initial version adding translation back and forth. Later versions of
the patch simply emit a warning and ignore the old value. Apparently nobody
noticed that the value became unused.)
This patch is a new attempt to fix the race originally described in issue #9754.
The initial fix (commit ad96887a12) consisted in
spawning a sub process that became the controlling process of the VT and hence
kicked the old controlling process off to make sure that the VT wouldn't have
entered in HUP state while logind restored the VT.
But it introduced a regression (see issue #11269) and thus was reverted. But
unlike it was described in the revert commit message, commit
adb8688b3f alone doen't fix the initial race.
This patch fixes the race in a simpler way by trying to restore the VT a second
time after making sure to re-open it if the first attempt fails.
Indeed if the old controlling process dies before or during the first attempt,
logind will fail to restore the VT. At this point the VT is in HUP state but
we're sure that it won't enter in a HUP state a second time. Therefore we will
retry by re-opening the VT to clear the HUP state and by restoring the VT a
second time, which should be safe this time.
Fixes: #9754Fixes: #13241
Allow earlier PAM modules to set `systemd.runtime_max_sec`. If they do,
parse it and set it as the `RuntimeMaxUSec=` property of the session
scope, to limit the maximum lifetime of the session. This could be
useful for time-limiting login sessions, for example.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #12035
The same as parent commit, but users. This is the third and last
foo_object_find() function in logind, so I think that this particular
family of bugs is finally squashed.
The story is the same as in 471cffcfb0e005b7c4044b3b52cc4f25d217efac:
device_attach() → seat_send_changed() → sd_bus_emit_properties_changed_strv()
→ emit_properties_changed_on_interface() → node_vtable_get_userdata()
→ seat_object_find(), which returns 0 because message == NULL.
But when we are emitting a signal, message is always NULL. Removing the
overeager check and assert in the called function allow the signal to be
emitted.
Fixes#13769.
For executables which take a verb, we should list the verbs first, and
then options which modify those verbs second. The general layout of
the man page is from general description to specific details, usually
Overview, Commands, Options, Return Value, Examples, References.
As documented in the man-page, readdir() may return a directory entry with
d_type == DT_UNKNOWN. This must be handled for regular filesystems.
dirent_ensure_type() is available to set d_type if necessary. Use it in
some more places.
Without this systemd will fail to boot correctly with nfsroot and some
other filesystems.
Closes#13609
I want to use efivars.[ch] in proc-cmdline.c, but most of the efivars stuff is
not needed in basic/. Move the file from shared/ to basic/, but then move back
most of the higher-level functions to the new shared/efi-loader.c file.
This way less stuff needs to be in basic. Initially, I wanted to move all the
parts of cgroup-utils.[ch] that depend on efivars.[ch] to shared, because
efivars.[ch] is in shared/. Later on, I decide to split efivars.[ch], so the
move done in this patch is not necessary anymore. Nevertheless, it is still
valid on its own. If at some point we want to expose libbasic, it is better to
to not have stuff that belong in libshared there.
We would not send the property because we'd call sd_bus_get_current_message()
which would return NULL. If there is no message, we cannot support /self or
/auto, but things are still OK if a path with a session name is given.
Traceback when the issue is triggered:
#2 we'd call sd_bus_get_current_message() here, which would return NULL, and
session_object_find() would immediately return 0.
#3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2",
interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0)
at ../src/login/logind-session-dbus.c:620
#4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2",
c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37
#5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110,
prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2",
interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163,
names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088
#6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110,
path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session",
names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291
#7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active")
at ../src/login/logind-session-dbus.c:730
#8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249
#9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361
#10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395
#11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0)
at ../src/login/logind.c:588
#12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828
#13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241
#14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615)
at ../src/libsystemd/sd-event/sd-event.c:3299
#15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186
#16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234
#17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244
Fixes#13437. Bug introduced in 3b92c086a8.
Let's follow our modern style (i.e. return proper errors, use structure
initialization and _cleanup_).
Most importantly: remove state file and FIFO removal from
inhibitor_free() and let's move it to inhibitor_stop().
This makes sure that state files/FIFOs are not removed when the we
terminate logind, i.e. that they can survive logind restarts.
Fixes: #11825
Also make some parsing errors, fatals and others (that just care fore
'decoration') non-fatal.
The single caller of inhibitor_load() didn't log about any errors, hence
let's do this in our function, similar to how this is done in
session_load() already.
For some reason, systemd-logind is trying to handle idle action in one of my containers:
Jun 07 10:28:08 rawhide systemd-logind[42]: System idle. Taking action.
Jun 07 10:28:08 rawhide systemd-logind[42]: Requested operation not supported, ignoring.
But we didn't log what exactly was being done. Let's put the name of the action in messages.
All callers pass either a fixed action, or HANDLE_IGNORE is explicitly filtered
out. Let's remove this case here, because we cannot properly log what opreation
we are ignoring.
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.
When emitting the calendarspec warning we want to see some color.
Follow-up for 04220fda5c.
Exceptions:
- systemctl, because it has a lot hand-crafted coloring
- tmpfiles, sysusers, stdio-bridge, etc, because they are also used in
services and I'm not sure if this wouldn't mess up something.
This is partially a refactoring, but also makes many more places use
unlocked operations implicitly, i.e. all users of fopen_temporary().
AFAICT, the uses are always for short-lived files which are not shared
externally, and are just used within the same context. Locking is not
necessary.
let's use sd_notifyf(). Let's also stop validating the session ID here.
This is the destructor. if it contains a dash, we are already too late
here anyway.
Let's be helpful to static analyzers which care about whether we
knowingly ignore return values. We do in these cases, since they are
usually part of error paths.
This adds support for user to set & get reboot parameter for reboot.
As callee would be next issuing Reboot call same policy checks are being used.
If unit file issuing the reboot action defines RebootArgument (or similar) that
setting takes precedence.
Setting an access mode != 0666 is explicitly supported via -Dgroup-render-mode
In such a case, re-add the uaccess tag.
This is basically the same change that was done for /dev/kvm in
commit fa53e24130 and
ace5e3111c
and partially reverts the changes from
4e15a7343c
When 'nomodeset' is specified, there's no DRM driver to take over from
efifb. This means no device will be marked as a seat master, so gdm will
never find a sufficiently active seat to start on.
I'm not aware of an especially good way to detect this through a proper
kernel API, so check for the word 'nomodeset' on the command line and
allow fbdev devices to be seat masters if found.
For https://bugzilla.redhat.com/show_bug.cgi?id=1683197.
This behaves similar to the "boot into firmware" logic, and also allows
either direct EFI operation (which sd-boot supports and others might
support eventually too) or override through env var.
This extends the reboot-to-firmware logic in logind, so that other than
EFI firmwares could be theoretically support. The scheme is like this:
if you want to support this, set the $SYSTEMD_REBOOT_TO_FIRMWARE=1 env
var for logind. If so, this will override the EFI logic, and cause a
file /run/systemd/reboot-to-firmware file to be created when
reboot-to-firmware is requested. This file has no contents, it's mere
existance indicates a reboot with reboot-to-firmware set.
The idea is that for alternative firmwares a drop-in for logind is added
that sets the env var, in combination with some code run during shutdown
that checks for the file and does the right thing.
User instance of systemd is optional feature and if user@.service
template is masked then administrator most likely doesn't want --user
instances of systemd for logged in users. We don't need to be verbose
about it.
This enables graphical capability for a video adapter of Parallels
virtualization platform (Parallels Desktop for Mac product) which is not
a DRM device at the moment.
This fixes GUI in Fedora 29 guest on Parallels Desktop where gdm now
strictly checks for CanGraphical property of a seat, see [1].
Should be noted that there's no in-kernel driver for Parallels video at
the moment so device matching is done by vid/pid.
[1] https://gitlab.gnome.org/GNOME/gdm/merge_requests/37
This reverts commit 69bd76f2b9.
$DBUS_SESSION_BUS_ADDRESS is again set only if the socket exists.
Quoting https://github.com/systemd/systemd/pull/11327#issuecomment-452019027:
> [setting $DBUS_SESSION_BUS_ADDRESS unconditionally] makes pam_systemd
> incompatible with installations and distributions where dbus was not
> configured with --enable-user-session, and the session dbus-daemon is started
> by autolaunching or dbus-launch (as opposed to dbus.socket). I don't think
> that's wise: using autolaunching or dbus-launch, and disabling or not
> installing dbus.socket and dbus.service on the systemd user instance, is our
> compatibility story for people who still need a D-Bus session bus per X11
> session for whatever reason.
>
> For example, Debian can currently do either way, with a dbus-user-session
> package strongly recommended but not actually mandatory. dbus-user-session
> requires libpam-systemd; if pam_systemd now requires dbus.socket (which is in
> the dbus-user-session package), that's a circular dependency, which we
> normally try hard to avoid.
For systems that use dbus.socket this doesn't matter much, because the
user session is ordered after the user managaer, which pulls in dbus.socket
very early. For example, when logging over ssh:
sshd[20796]: pam_systemd(sshd:session): pam-systemd initializing
sshd[20796]: pam_systemd(sshd:session): Asking logind to create session: uid=1001 pid=20796 service=sshd type=tty class=user desktop= seat= vtnr=0 tty= display= remote=yes remote_user= remote_host=::1
sshd[20796]: pam_systemd(sshd:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a
systemd[1]: Created slice User Slice of UID 1001.
systemd[1]: Starting User Runtime Directory /run/user/1001...
systemd-logind[1210]: New session 3796 of user guest.
systemd[1]: Started User Runtime Directory /run/user/1001.
systemd[1]: Starting User Manager for UID 1001...
systemd[20805]: pam_systemd(systemd-user:session): pam-systemd initializing
systemd[20805]: Starting D-Bus User Message Bus Socket.
...
systemd[20805]: Reached target Sockets.
systemd[20805]: Reached target Basic System.
systemd[1]: Started User Manager for UID 1001.
systemd[1]: Started Session 3796 of user guest.
sshd[20796]: pam_systemd(sshd:session): Reply from logind: id=3796 object_path=/org/freedesktop/login1/session/_33796 runtime_path=/run/user/1001 session_fd=13 seat= vtnr=0 original_uid=1001
sshd[20796]: pam_unix(sshd:session): session opened for user guest by (uid=0)
Hence, everything in the ssh session is ordered after the user instance.
And in the user instance, services should be orderd after dbus.socket using
inter-unit dependencies. dbus.socket in turns does
systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus.
So there should be no race between starting of the dbus socket and our check
if it exists.
The alternative would be to set the "DBUS_SESSION_BUS_ADDRESS=unix:path=%s/bus;autolaunch:".
AFAICT, this would work as well. But I don't see any case where it actually works
better. Since this is an area with many compatiblity concerns, let's stick to
the previous setup which seems to work well.
