Let's not trigger MACs needlessly.
Ideally everybody would turn on userdb, but if people insist in not
doing so, then let's not attempt to open shadow.
It's a bit ugly to implement this, since shadow information is more than
just passwords (but accound validity metadata), and thus userdb's own
"privieleged" scheme is orthogonal to this, but let's still do this for
the client side.
Fixes: #15105
When starting a wayland session through a systemd service for a non-root
user, the compositor (based on wlroots) is denied the authorization to
change vt.
Once the user logs in, either through a local console or via ssh, the
compositor can work properly.
This is related to the login polkit policy:
- `allow_inactive` has value `auth_admin_keep`, denying any non-root
user session the authorization to change vt
- `allow_active` has value `yes`, which explains why the vt change
becomes possible once the user logs in through another channel
By changing the `allow_inactive` value to `yes`, any user session setup
in a service file can switch vt, allowing wayland sessions for non-root
users.
We used to log the following error:
"Start job for unit user-1000.slice failed with 'canceled'"
which can be really misleading if the actual job failed at *stopping* a unit.
Indeed "Start" was hard coded but it was wrong since we can also fail with stop
jobs which are enqueued when a session is stopped.
It fully initializes the address structure, so no need for pre-initialization,
and also returns the length of the address, so no need to recalculate using
SOCKADDR_UN_LEN().
socklen_t is unsigned, so let's not use an int for it. (It doesn't matter, but
seems cleaner and more portable to not assume anything about the type.)
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.
