ca56b0a68300b035c605bedc5b339128897debfc |
|
18-Jan-2015 |
David Herrmann <dh.herrmann@gmail.com> |
logind: hide 'self' links if not available
If the caller does not run in a session/seat or has no tracked user, hide
the /org/freedesktop/login1/.../self links in introspection data.
Otherwise, "busctl tree org.freedesktop.login1" tries to query those nodes
even though it cant. |
309a29dfd24f4175de334ca1593e3fe2436ab082 |
|
09-Jan-2015 |
Lennart Poettering <lennart@poettering.net> |
logind: when a bus call is done on a session, user or seat, optionally determine them from the caller credentials
More specifically, if an operation is requested on a session with an
empty name, the caller's session is used. If an operation is requested
on a seat with an empty name, the seat of the caller's session is used.
Finally, if an operation on the user with UID -1 is requested, the user
of the client's session is used (and not the UID of the client!). |
49e6fdbf14b35d8840c3b263fd15259624b07818 |
|
20-Jan-2014 |
David Herrmann <dh.herrmann@gmail.com> |
logind: introduce session "positions"
logind has no concept of session ordering. Sessions have a unique name,
some attributes about the capabilities and that's already it. There is
currently no stable+total order on sessions. If we use the logind API to
switch between sessions, we are faced with an unordered list of sessions
we have no clue of.
This used to be no problem on seats with VTs or on seats with only a
single active session. However, with the introduction of multi-session
capability for seats without VTs, we need to find a way to order sessions
in a stable way.
This patch introduces session "positions". A position is a simple integer
assigned to a session which is never changed implicitly (currently, we
also don't change it explicitly, but that may be changed someday). For
seats with VTs, we force the position to be the same as the VTnr. Without
VTs, we simply find the lowest unassigned number and use it as position.
If position-assignment fails or if, for any reason, we decide to not
assign a position to a session, the position is set to 0 (which is treated
as invalid position).
During session_load() or if two sessions have the same VTnr, we may end up
with two sessions with the same position (this shouldn't happen, but lets
be fail-safe in case some other part of the stack fails). This case is
dealt with gracefully by ignoring any session but the first session
assigned to the position. Thus, session->pos is a hint, seat->positions[i]
is the definite position-assignment. Always verify both match in case you
need to modify them!
Additionally, we introduce SwitchTo(unsigned int) on the seat-dbus-API.
You can call it with any integer value != 0 and logind will try to switch
to the request position. If you implement a compositor or any other
session-controller, you simply watch for ctrl+alt+F1 to F12 and call
SwitchTo(Fx). logind will figure a way out deal with this number.
For convenience, we also introduce SwitchToNext/Previous(). It should be
called on ctrl+alt+Left/Right (like the kernel-console used to support).
Note that the public API (SwitchTo*()) is *not* bound to the underlying
logic that is implemented now. We don't export "session-positions" on the
dbus/C API! They are an implementation detail. Instead, the SwitchTo*()
API is supposed to be a hint to let logind choose the session-switching
logic. Any foreground session-controller is free to enumerate/order
existing sessions according to their needs and call Session.Activate()
manually. But the SwitchTo*() API provides a uniform behavior across
session-controllers.
Background: Session-switching keys depend on the active keymap. The XKB
specification provides the XKB_KEY_XF86Switch_VT_1-12 key-symbols which
have to be mapped by all keymaps to allow session-switching. It is usually
bound to ctrl+alt+Fx but may be set differently. A compositor passes any
keyboard input to XKB before passing it to clients. In case a key-press
invokes the XKB_KEY_XF86Switch_VT_x action, the keypress is *not*
forwarded to clients, but instead a session-switch is scheduled.
This actually prevents us from handling these keys outside of the session.
If an active compositor has a keymap with a different mapping of these
keys, and logind itself tries to catch these combinations, we end up with
the key-press sent to the compositor's clients *and* handled by logind.
This is *bad* and we must avoid this. The only situation where a
background process is allowed to handle key-presses is debugging and
emergency-keys. In these cases, we don't care for keymap mismatches and
accept the double-event. Another exception is unmapped keys like
PowerOff/Suspend (even though this one is controversial). |
adacb9575a09981fcf11279f2f661e3fc21e58ff |
|
10-Dec-2013 |
Lennart Poettering <lennart@poettering.net> |
bus: introduce "trusted" bus concept and encode access control in object vtables
Introduces a new concept of "trusted" vs. "untrusted" busses. For the
latter libsystemd-bus will automatically do per-method access control,
for the former all access is automatically granted. Per-method access
control is encoded in the vtables: by default all methods are only
accessible to privileged clients. If the SD_BUS_VTABLE_UNPRIVILEGED flag
is set for a method it is accessible to unprivileged clients too. By
default whether a client is privileged is determined via checking for
its CAP_SYS_ADMIN capability, but this can be altered via the
SD_BUS_VTABLE_CAPABILITY() macro that can be ORed into the flags field
of the method.
Writable properties are also subject to SD_BUS_VTABLE_UNPRIVILEGED and
SD_BUS_VTABLE_CAPABILITY() for controlling write access to them. Note
however that read access is unrestricted, as PropertiesChanged messages
might send out the values anyway as an unrestricted broadcast.
By default the system bus is set to "untrusted" and the user bus is
"trusted" since per-method access control on the latter is unnecessary.
On dbus1 busses we check the UID of the caller rather than the
configured capability since the capability cannot be determined without
race. On kdbus the capability is checked if possible from the attached
meta-data of a message and otherwise queried from the sending peer.
This also decorates the vtables of the various daemons we ship with
these flags. |
f1a8e221ecacea23883df57951e291a910463948 |
|
21-Jun-2012 |
Lennart Poettering <lennart@poettering.net> |
logind: expose CanGraphical and CanTTY properties on seat objects
Since we boot so fast now that gdm might get started before the
graphics drivers are properly loaded and probed we might end up
announcing seat0 to gdm before it has graphics capabilities. Which will
cause gdm/X11 cause to fail later on.
To fix this race, let's expose CanGraphical and CanTTY fields on all
seats, which clarify whether a seat is suitable for gdm resp, suitable
for text logins. gdm then needs to watch CanGraphical and spawn X11 on
it only if it is true.
This way:
USB graphics seats will expose CanGraphical=yes, CanTTY=no
Machines with no graphics drivers at all, but a text console:
CanGraphical=no, CanTTY=yes
Machines with CONFIG_VT turned off: CanGraphical=yes, CanTTY=no
And the most important case: seat0 where the graphics driver has not
been probed yet boot up with CanGraphical=no, CanTTY=yes first, which
then changes to CanGraphical=yes as soon as the probing is complete. |