1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
// Copyright (C) 2016-2017 Luke Shumaker <lukeshu@sbcglobal.net>
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
// Package sd_login introspects session and login information from
// systemd, logind, and machined.
//
// There are 5 basic object types that these three system services
// manage and are introspected by this package.
//
// The machine manager maintains a list of "machines":
//
// 1. machine: A local container or virtual machine
//
// The host system, and machines hosted on it, may each run their own
// login manager, which keeps track of "seats", "sessions", and
// "users":
//
// 2. seat: A set of hardware devices for a workspace; i.e. a screen
// and keyboard
//
// 3. session: A login session; tied to 0 or 1 seats (0 for things
// like SSH login)
//
// 4. user: Keeps track of logged in users; that is, users with 1 or
// more sessions
//
// Finally, sessions and users can be used to group together
// "processes", which are kept track of by cgroup manager:
//
// 5. process: A process may belong to a session, or directly to a
// user if it is not part of a session. This "belonging" is
// separate accounting by the cgroup manager; it is NOT the same
// as the EUID/RUID.
//
// How these relations look in the types implemented here:
//
// ............................................
// . .
// . +-------------+ .
// . | MachineName | .
// . +-------------+ .
// . ^ .
// . | .
// . |GetMachine() .
// . | .
// . ^ .
// . +-----------+ .
// . | ProcessID | .
// . +-----------+ .
// . v v .
// . | | .
// . GetSession() | | GetOwner() .
// . ,--------' '-------, .
// . | | .
// . v v .
// . +-------------+ GetUser() +--------+ .
// . | SessionName |>--------->| UserID | .
// . +-------------+ +--------+ .
// . v^^ ^ GetSessions() v .
// . ||| `---------------' .
// . ||| .
// . GetSeat()||GetSessions() .
// . |||GetActive() .
// . v^^ .
// . +----------+ .
// . | SeatName | .
// . +----------+ .
// . .
// ............................................
//
// Missing from the above diagram:
//
// - As an optimization, SeatName.GetSessions() and .GetActive()
// return both the session name, and the user ID that owns the
// session. This is equivalent to just calling .GetUser() on the
// returned session.
//
// - There is also a UserID.GetSeats() that is equivalent to calling
// UserID.GetSessions(), and calling .GetSeat() on each returned
// session.
//
// TODO: Better describe how machines fit in; the high-level
// description doesn't really match the interface exposed (as evident
// by a glance at the diagram).
//
// Finally, if you would like to perform some action whenever a
// machine, seat, session, or logged-in-user is added or removed,
// there is a Monitor that will help you avoid polling.
package sd_login
|
