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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
'\" t
.TH "SYSTEMD\-HOMED\&.SERVICE" "8" "" "systemd 256~rc3" "systemd-homed.service"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
systemd-homed.service, systemd-homed \- Home Area/User Account Manager
.SH "SYNOPSIS"
.PP
systemd\-homed\&.service
.PP
/usr/lib/systemd/systemd\-homed
.SH "DESCRIPTION"
.PP
\fBsystemd\-homed\fR
is a system service that may be used to create, remove, change or inspect home areas (directories and network mounts and real or loopback block devices with a filesystem, optionally encrypted)\&.
.PP
Most of
\fBsystemd\-homed\fR\*(Aqs functionality is accessible through the
\fBhomectl\fR(1)
command\&.
.PP
See the
\m[blue]\fBHome Directories\fR\m[]\&\s-2\u[1]\d\s+2
documentation for details about the format and design of home areas managed by
systemd\-homed\&.service\&.
.PP
Each home directory managed by
systemd\-homed\&.service
synthesizes a local user and group\&. These are made available to the system using the
\m[blue]\fBUser/Group Record Lookup API via Varlink\fR\m[]\&\s-2\u[2]\d\s+2, and thus may be browsed with
\fBuserdbctl\fR(1)\&.
.PP
systemd\-homed\&.service
also manages blob directories for each home directory it manages\&. See
\m[blue]\fBUser Record Blob Directories\fR\m[]\&\s-2\u[3]\d\s+2
for more details\&.
.SH "KEY MANAGEMENT"
.PP
User records are cryptographically signed with a public/private key pair (the signature is part of the JSON record itself)\&. For a user to be permitted to log in locally the public key matching the signature of their user record must be installed\&. For a user record to be modified locally the private key matching the signature must be installed locally, too\&. The keys are stored in the
/var/lib/systemd/home/
directory:
.PP
/var/lib/systemd/home/local\&.private
.RS 4
The private key of the public/private key pair used for local records\&. Currently, only a single such key may be installed\&.
.sp
Added in version 246\&.
.RE
.PP
/var/lib/systemd/home/local\&.public
.RS 4
The public key of the public/private key pair used for local records\&. Currently, only a single such key may be installed\&.
.sp
Added in version 246\&.
.RE
.PP
/var/lib/systemd/home/*\&.public
.RS 4
Additional public keys\&. Any users whose user records are signed with any of these keys are permitted to log in locally\&. An arbitrary number of keys may be installed this way\&.
.sp
Added in version 246\&.
.RE
.PP
All key files listed above are in PEM format\&.
.PP
In order to migrate a home directory from a host
"foobar"
to another host
"quux"
it is hence sufficient to copy
/var/lib/systemd/home/local\&.public
from the host
"foobar"
to
"quux", maybe calling the file on the destination
/var/lib/systemd/home/foobar\&.public, reflecting the origin of the key\&. If the user record should be modifiable on
"quux"
the pair
/var/lib/systemd/home/local\&.public
and
/var/lib/systemd/home/local\&.private
need to be copied from
"foobar"
to
"quux", and placed under the identical paths there, as currently only a single private key is supported per host\&. Note of course that the latter means that user records generated/signed before the key pair is copied in, lose their validity\&.
.SH "SEE ALSO"
.PP
\fBsystemd\fR(1), \fBhomed.conf\fR(5), \fBhomectl\fR(1), \fBpam_systemd_home\fR(8), \fBuserdbctl\fR(1), \fBorg.freedesktop.home1\fR(5)
.SH "NOTES"
.IP " 1." 4
Home Directories
.RS 4
\%https://systemd.io/HOME_DIRECTORY
.RE
.IP " 2." 4
User/Group Record Lookup API via Varlink
.RS 4
\%https://systemd.io/USER_GROUP_API
.RE
.IP " 3." 4
User Record Blob Directories
.RS 4
\%https://systemd.io/USER_RECORD_BLOB_DIRS
.RE
|
