1SD-LOGIN(3) sd-login SD-LOGIN(3)
2
6 sd-login - APIs for tracking logins
7
9 #include <systemd/sd-login.h>
10 pkg-config --cflags --libs libsystemd
12
14 sd-login.h provides APIs to introspect and monitor seat, login session
15 and user status information on the local system.
16 Note that these APIs only allow purely passive access and monitoring of
18 seats, sessions and users. To actively make changes to the seat
19 configuration, terminate login sessions, or switch session on a seat
20 you need to utilize the D-Bus API of systemd-logind, instead.
21 These functions synchronously access data in /proc, /sys/fs/cgroup and
23 /run. All of these are virtual file systems, hence the runtime cost of
24 the accesses is relatively cheap.
25 It is possible (and often a very good choice) to mix calls to the
27 synchronous interface of sd-login.h with the asynchronous D-Bus
28 interface of systemd-logind. However, if this is done you need to think
29 a bit about possible races since the stream of events from D-Bus and
30 from sd-login.h interfaces such as the login monitor are asynchronous
31 and not ordered against each other.
32 If the functions return string arrays, these are generally NULL
34 terminated and need to be freed by the caller with the libc free(3)
35 call after use, including the strings referenced therein. Similarly,
36 individual strings returned need to be freed, as well.
37 As a special exception, instead of an empty string array NULL may be
39 returned, which should be treated equivalent to an empty string array.
40 See sd_pid_get_session(3), sd_uid_get_state(3),
42 sd_session_is_active(3), sd_seat_get_active(3), sd_get_seats(3),
43 sd_login_monitor_new(3) for more information about the functions
44 implemented.
45
47 seat
48 A seat consists of all hardware devices assigned to a specific
49 workplace. It consists of at least one graphics device, and usually
50 also includes keyboard, mouse. It can also include video cameras,
51 sound cards and more. Seats are identified by seat names, which are
52 strings (<= 255 characters), that start with the four characters
53 "seat" followed by at least one character from the range
54 [a-zA-Z0-9], "_" and "-". They are suitable for use as file names.
55 Seat names may or may not be stable and may be reused if a seat
56 becomes available again.
57 session
59 A session is defined by the time a user is logged in until they log
60 out. A session is bound to one or no seats (the latter for
61 'virtual' ssh logins). Multiple sessions can be attached to the
62 same seat, but only one of them can be active, the others are in
63 the background. A session is identified by a short string.
64 systemd(1) ensures that audit sessions are identical to systemd
66 sessions, and uses the audit session ID as session ID in systemd
67 (if auditing is enabled). In general the session identifier is a
68 short string consisting only of [a-zA-Z0-9], "_" and "-", suitable
69 for use as a file name. Session IDs are unique on the local machine
70 and are never reused as long as the machine is online. A user (the
71 way we know it on UNIX) corresponds to the person using a computer.
72 A single user can have multiple sessions open at the same time. A
73 user is identified by a numeric user id (UID) or a user name (a
74 string). A multi-session system allows multiple user sessions on
75 the same seat at the same time. A multi-seat system allows multiple
76 independent seats that can be individually and simultaneously used
77 by different users.
78 All hardware devices that are eligible to being assigned to a seat, are
80 assigned to one. A device can be assigned to only one seat at a time.
81 If a device is not assigned to any particular other seat it is
82 implicitly assigned to the special default seat called "seat0".
83 Note that hardware like printers, hard disks or network cards is
85 generally not assigned to a specific seat. They are available to all
86 seats equally. (Well, with one exception: USB sticks can be assigned to
87 a seat.)
88 "seat0" always exists.
90
92 Assignment of hardware devices to seats is managed inside the udev
93 database, via settings on the devices:
94 Tag "seat"
96 When set, a device is eligible to be assigned to a seat. This tag
97 is set for graphics devices, mice, keyboards, video cards, sound
98 cards and more. Note that some devices like sound cards consist of
99 multiple subdevices (i.e. a PCM for input and another one for
100 output). This tag will be set only for the originating device, not
101 for the individual subdevices. A UI for configuring assignment of
102 devices to seats should enumerate and subscribe to all devices with
103 this tag set and show them in the UI. Note that USB hubs can be
104 assigned to a seat as well, in which case all (current and future)
105 devices plugged into it will also be assigned to the same seat
106 (unless they are explicitly assigned to another seat).
107 Tag "master-of-seat"
109 When set, this device is enough for a seat to be considered
110 existent. This tag is usually set for the framebuffer device of
111 graphics cards. A seat hence consists of an arbitrary number of
112 devices marked with the "seat" tag, but (at least) one of these
113 devices needs to be tagged with "master-of-seat" before the seat is
114 actually considered to be around.
115 Property ID_SEAT
117 This property specifies the name of the seat a specific device is
118 assigned to. If not set the device is assigned to "seat0". Also, to
119 speed up enumeration of hardware belonging to a specific seat, the
120 seat is also set as tag on the device. I.e. if the property
121 ID_SEAT=seat-waldo is set for a device, the tag "seat-waldo" will
122 be set as well. Note that if a device is assigned to "seat0", it
123 will usually not carry such a tag and you need to enumerate all
124 devices and check the ID_SEAT property manually. Again, if a device
125 is assigned to seat0 this is visible on the device in two ways:
126 with a property ID_SEAT=seat0 and with no property ID_SEAT set for
127 it at all.
128 Property ID_AUTOSEAT
130 When set to "1", this device automatically generates a new and
131 independent seat, which is named after the path of the device. This
132 is set for specialized USB hubs like the Plugable devices, which
133 when plugged in should create a hotplug seat without further
134 configuration.
135 Property ID_FOR_SEAT
137 When creating additional (manual) seats starting from a graphics
138 device this is a good choice to name the seat after. It is created
139 from the path of the device. This is useful in UIs for configuring
140 seats: as soon as you create a new seat from a graphics device,
141 read this property and prefix it with "seat-" and use it as name
142 for the seat.
143 A seat exists only and exclusively because a properly tagged device
145 with the right ID_SEAT property exists. Besides udev rules there is no
146 persistent data about seats stored on disk.
147 Note that systemd-logind(8) manages ACLs on a number of device classes,
149 to allow user code to access the device nodes attached to a seat as
150 long as the user has an active session on it. This is mostly
151 transparent to applications. As mentioned above, for certain user
152 software it might be a good idea to watch whether they can access
153 device nodes instead of thinking about seats.
154
156 These APIs are implemented as a shared library, which can be compiled
157 and linked to with the libsystemd pkg-config(1) file.
158
160 systemd(1), sd_pid_get_session(3), sd_uid_get_state(3),
161 sd_session_is_active(3), sd_seat_get_active(3), sd_get_seats(3),
162 sd_login_monitor_new(3), sd-daemon(3), pkg-config(1)
163 Multi-Seat on Linux[1] for an introduction to multi-seat support on
165 Linux and the background for this set of APIs.
166
168 1. Multi-Seat on Linux
169 https://www.freedesktop.org/wiki/Software/systemd/multiseat
170systemd 243 SD-LOGIN(3)