chiark / gitweb /
man: add missing headers to glib-event-glue.c
[elogind.git] / man / sd-login.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4
5 <!--
6   SPDX-License-Identifier: LGPL-2.1+
7
8   This file is part of systemd.
9
10   Copyright 2010 Lennart Poettering
11
12   systemd is free software; you can redistribute it and/or modify it
13   under the terms of the GNU Lesser General Public License as published by
14   the Free Software Foundation; either version 2.1 of the License, or
15   (at your option) any later version.
16
17   systemd is distributed in the hope that it will be useful, but
18   WITHOUT ANY WARRANTY; without even the implied warranty of
19   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
20   Lesser General Public License for more details.
21
22   You should have received a copy of the GNU Lesser General Public License
23   along with systemd; If not, see <http://www.gnu.org/licenses/>.
24 -->
25
26 <refentry id="sd-login" conditional='HAVE_PAM'
27   xmlns:xi="http://www.w3.org/2001/XInclude">
28
29   <refentryinfo>
30     <title>sd-login</title>
31     <productname>systemd</productname>
32
33     <authorgroup>
34       <author>
35         <contrib>Developer</contrib>
36         <firstname>Lennart</firstname>
37         <surname>Poettering</surname>
38         <email>lennart@poettering.net</email>
39       </author>
40     </authorgroup>
41   </refentryinfo>
42
43   <refmeta>
44     <refentrytitle>sd-login</refentrytitle>
45     <manvolnum>3</manvolnum>
46   </refmeta>
47
48   <refnamediv>
49     <refname>sd-login</refname>
50     <refpurpose>APIs for
51     tracking logins</refpurpose>
52   </refnamediv>
53
54   <refsynopsisdiv>
55     <funcsynopsis>
56       <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
57     </funcsynopsis>
58
59     <cmdsynopsis>
60       <command>pkg-config --cflags --libs libelogind</command>
61     </cmdsynopsis>
62   </refsynopsisdiv>
63
64   <refsect1>
65     <title>Description</title>
66
67     <para><filename>sd-login.h</filename> provides APIs to introspect
68     and monitor seat, login session and user status information on the
69     local system. </para>
70
71     <para>Note that these APIs only allow purely passive access and
72     monitoring of seats, sessions and users. To actively make changes
73     to the seat configuration, terminate login sessions, or switch
74     session on a seat you need to utilize the D-Bus API of
75     systemd-logind, instead.</para>
76
77     <para>These functions synchronously access data in
78     <filename>/proc</filename>, <filename>/sys/fs/cgroup</filename>
79     and <filename>/run</filename>. All of these are virtual file
80     systems, hence the runtime cost of the accesses is relatively
81     cheap.</para>
82
83     <para>It is possible (and often a very good choice) to mix calls
84     to the synchronous interface of <filename>sd-login.h</filename>
85     with the asynchronous D-Bus interface of systemd-logind. However,
86     if this is done you need to think a bit about possible races since
87     the stream of events from D-Bus and from
88     <filename>sd-login.h</filename> interfaces such as the login
89     monitor are asynchronous and not ordered against each
90     other.</para>
91
92     <para>If the functions return string arrays, these are generally
93     <constant>NULL</constant> terminated and need to be freed by the
94     caller with the libc
95     <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
96     call after use, including the strings referenced therein.
97     Similarly, individual strings returned need to be freed, as
98     well.</para>
99
100     <para>As a special exception, instead of an empty string array
101     <constant>NULL</constant> may be returned, which should be treated
102     equivalent to an empty string array.</para>
103
104     <para>See
105     <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
106     <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
107     <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
108     <citerefentry><refentrytitle>sd_seat_get_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
109     <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
110     <citerefentry><refentrytitle>sd_login_monitor_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
111     for more information about the functions
112     implemented.</para>
113   </refsect1>
114
115   <refsect1>
116     <title>Definition of Terms</title>
117
118     <variablelist>
119       <varlistentry>
120         <term>seat</term>
121
122         <listitem><para>A seat consists of all hardware devices assigned to a specific
123         workplace. It consists of at least one graphics device, and usually also includes
124         keyboard, mouse. It can also include video cameras, sound cards and more. Seats
125         are identified by seat names, which are strings (&lt;= 255 characters), that start
126         with the four characters <literal>seat</literal> followed by at least one
127         character from the range [a-zA-Z0-9], <literal>_</literal> and
128         <literal>-</literal>. They are suitable for use as file names. Seat names may or
129         may not be stable and may be reused if a seat becomes available again.
130         </para></listitem>
131       </varlistentry>
132
133       <varlistentry>
134         <term>session</term>
135
136         <listitem><para>A session is defined by the time a user is logged in until they
137         log out. A session is bound to one or no seats (the latter for 'virtual' ssh
138         logins). Multiple sessions can be attached to the same seat, but only one of them
139         can be active, the others are in the background. A session is identified by a
140         short string.</para>
141
142         <para>
143         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
144         ensures that audit sessions are identical to systemd sessions, and uses the audit
145         session ID as session ID in systemd (if auditing is enabled). In general the
146         session identifier is a short string consisting only of [a-zA-Z0-9],
147         <literal>_</literal> and <literal>-</literal>, suitable for use as a file name.
148         Session IDs are unique on the local machine and are
149         never reused as long as the machine is online. A user (the way we know it on UNIX)
150         corresponds to the person using a computer. A single user can have multiple
151         sessions open at the same time. A user is identified by a numeric user id (UID) or
152         a user name (a string). A multi-session system allows multiple user sessions on
153         the same seat at the same time. A multi-seat system allows multiple independent
154         seats that can be individually and simultaneously used by different users.</para>
155         </listitem>
156       </varlistentry>
157     </variablelist>
158
159     <para>All hardware devices that are eligible to being assigned to a seat, are assigned
160     to one. A device can be assigned to only one seat at a time. If a device is not
161     assigned to any particular other seat it is implicitly assigned to the special default
162     seat called <literal>seat0</literal>.</para>
163
164     <para>Note that hardware like printers, hard disks or network cards is generally not
165     assigned to a specific seat. They are available to all seats equally. (Well, with one
166     exception: USB sticks can be assigned to a seat.)</para>
167
168     <para><literal>seat0</literal> always exists.</para>
169   </refsect1>
170
171   <refsect1>
172     <title>udev Rules</title>
173
174     <para>Assignment of hardware devices to seats is managed inside the udev database, via
175     settings on the devices:</para>
176
177     <variablelist>
178       <varlistentry>
179         <term>Tag <literal>seat</literal></term>
180
181         <listitem><para>When set, a device is eligible to be assigned to a seat. This tag
182         is set for graphics devices, mice, keyboards, video cards, sound cards and
183         more. Note that some devices like sound cards consist of multiple subdevices
184         (i.e. a PCM for input and another one for output). This tag will be set only for
185         the originating device, not for the individual subdevices. A UI for configuring
186         assignment of devices to seats should enumerate and subscribe to all devices with
187         this tag set and show them in the UI. Note that USB hubs can be assigned to a seat
188         as well, in which case all (current and future) devices plugged into it will also
189         be assigned to the same seat (unless they are explicitly assigned to another
190         seat).
191         </para></listitem>
192       </varlistentry>
193
194       <varlistentry>
195         <term>Tag <literal>master-of-seat</literal></term>
196
197         <listitem><para>When set, this device is enough for a seat to be considered
198         existent. This tag is usually set for the framebuffer device of graphics cards. A
199         seat hence consists of an arbitrary number of devices marked with the
200         <literal>seat</literal> tag, but (at least) one of these devices needs to be
201         tagged with <literal>master-of-seat</literal> before the seat is actually
202         considered to be around.</para></listitem>
203       </varlistentry>
204
205       <varlistentry>
206         <term>Property <varname>ID_SEAT</varname></term>
207
208         <listitem><para>This property specifies the name of the seat a specific device is
209         assigned to. If not set the device is assigned to <literal>seat0</literal>. Also,
210         to speed up enumeration of hardware belonging to a specific seat, the seat is also
211         set as tag on the device. I.e. if the property
212         <varname>ID_SEAT=seat-waldo</varname> is set for a device, the tag
213         <literal>seat-waldo</literal> will be set as well. Note that if a device is
214         assigned to <literal>seat0</literal>, it will usually not carry such a tag and you
215         need to enumerate all devices and check the <varname>ID_SEAT</varname> property
216         manually. Again, if a device is assigned to seat0 this is visible on the device in
217         two ways: with a property <varname>ID_SEAT=seat0</varname> and with no property
218         <varname>ID_SEAT</varname> set for it at all.</para></listitem>
219       </varlistentry>
220
221       <varlistentry>
222         <term>Property <varname>ID_AUTOSEAT</varname></term>
223
224         <listitem><para>When set to <literal>1</literal>, this device automatically
225         generates a new and independent seat, which is named after the path of the
226         device. This is set for specialized USB hubs like the Plugable devices, which when
227         plugged in should create a hotplug seat without further configuration.</para>
228         </listitem>
229       </varlistentry>
230
231       <varlistentry>
232         <term>Property <varname>ID_FOR_SEAT</varname></term>
233
234         <listitem><para>When creating additional (manual) seats starting from a graphics
235         device this is a good choice to name the seat after. It is created from the path
236         of the device. This is useful in UIs for configuring seats: as soon as you create
237         a new seat from a graphics device, read this property and prefix it with
238         <literal>seat-</literal> and use it as name for the seat.</para></listitem>
239       </varlistentry>
240     </variablelist>
241
242     <para>A seat exists only and exclusively because a properly tagged device with the
243     right <varname>ID_SEAT</varname> property exists. Besides udev rules there is no
244     persistent data about seats stored on disk.</para>
245
246     <para>Note that
247     <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
248     manages ACLs on a number of device classes, to allow user code to access the device
249     nodes attached to a seat as long as the user has an active session on it. This is
250     mostly transparent to applications. As mentioned above, for certain user software it
251     might be a good idea to watch whether they can access device nodes instead of thinking
252     about seats.</para>
253   </refsect1>
254
255   <xi:include href="libelogind-pkgconfig.xml" />
256
257   <refsect1>
258     <title>See Also</title>
259     <para>
260       <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
261       <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
262       <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
263       <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
264       <citerefentry><refentrytitle>sd_seat_get_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
265       <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
266       <citerefentry><refentrytitle>sd_login_monitor_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
267       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
268       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
269     </para>
270
271     <para>
272       <ulink url="https://www.freedesktop.org/wiki/Software/systemd/multiseat">Multi-Seat on Linux</ulink>
273       for an introduction to multi-seat support on Linux and the background for this set of APIs.
274     </para>
275   </refsect1>
276
277 </refentry>