Compare commits

...

8 Commits

Author SHA1 Message Date
Yu Watanabe 4d2db005d8
Merge pull request #14701 from keszybz/homed-fixups
Trivial homed fixups
2020-01-31 00:09:39 +09:00
mtron 58345a2332
docs: formatting fix (#14707)
fixes formatting in the last paragraph of the 'General Structure' chapter.
2020-01-31 00:06:57 +09:00
Piotr Drąg 258adeca3c po: add src/home/org.freedesktop.home1.policy to POTFILES.in 2020-01-30 23:53:14 +09:00
mtron 56b3eddb70 fix links to GROUP_RECORD and USER_GROUP_API
fix 2 more broken links. 

GROUP_RECORD now points to https://systemd.io/GROUP_RECORD/ and 
USER_GROUP_API to https://systemd.io/USER_GROUP_API/
2020-01-30 23:48:44 +09:00
mtron e5e529c30a fix link to JSON User Records 2020-01-30 23:32:17 +09:00
Zbigniew Jędrzejewski-Szmek 2a4be3c52b Various typo fixes and grammar corrections 2020-01-30 13:48:01 +01:00
Zbigniew Jędrzejewski-Szmek 402058dc3a polkit: tweak grammar 2020-01-30 12:34:05 +01:00
Zbigniew Jędrzejewski-Szmek ec74f47e56 meson: fix type of homed option 2020-01-30 12:33:06 +01:00
12 changed files with 38 additions and 35 deletions

4
TODO
View File

@ -104,7 +104,7 @@ Features:
device node of current system, /usr device node, and matching verity, so that
an installer can be made a "copy" installer of the booted OS
* systemd-repart: make it a static checker during early boot for existance and
* systemd-repart: make it a static checker during early boot for existence and
absence of other partitions for trusted boot environments
* systemd-repart: when no configuration is found, exit early do not check
@ -114,7 +114,7 @@ Features:
* userdb: allow username prefix searches in varlink API
* userdb: allow existance checks
* userdb: allow existence checks
* pid: activation by journal search expression

View File

@ -18,7 +18,7 @@ used.
Inside of the home directory a file `~/.identity` contains the JSON formatted
user record of the user. It follows the format defined in [`JSON User
Records`](https://systemd.io/USER_RECORDS). It is recommended to bring the
Records`](https://systemd.io/USER_RECORD). It is recommended to bring the
record into 'normalized' form (i.e. all objects should contain their fields
sorted alphabetically by their key) before storing it there, though this is not
required nor enforced. Since the user record is cryptographically signed the

View File

@ -71,11 +71,11 @@ the following extensions are envisioned:
4. Default parameters for backup applications and similar
Similar to JSON User Records there are also [JSON Group
Records](https://systemd.io/GROUP_RECORD.md) that encapsulate UNIX groups.
Records](https://systemd.io/GROUP_RECORD) that encapsulate UNIX groups.
JSON User Records may be transferred or written to disk in various protocols
and formats. To inquire about such records defined on the local system use the
[User/Group Lookup API via Varlink](https://systemd.io/USER_GROUP_API.md).
[User/Group Lookup API via Varlink](https://systemd.io/USER_GROUP_API).
## Why JSON?
@ -184,7 +184,7 @@ does not need to to be concerned with the `secret` section of user records, as
the fields included therein are only useful when executing authentication
operations natively against JSON user records.
The `systemd-homed' manager uses all seven sections for various
The `systemd-homed` manager uses all seven sections for various
purposes. Inside the home directories (and if the LUKS2 backend is used, also
in the LUKS2 header) a user record containing the `regular`, `privileged`,
`perMachine` and `signature` sections is stored. `systemd-homed` also stores a

View File

@ -39,18 +39,19 @@
which manages home directories of users.</para>
<para>Home directories managed by <filename>systemd-homed.service</filename> are self-contained, and thus
include the user's full metadata record in the home's data storage itself, making them easily migratable
between machines. In particular a home directory in itself describes a matching user record, and every
user record managed by <filename>systemd-homed.service</filename> also implies existance and
encapsulation of a home directory. The user account and home directory hence become the same concept. The
following backing storage mechanisms are supported:</para>
include the user's full metadata record in the home's data storage itself, making them easy to migrate
between machines. In particular, a home directory describes a matching user record, and every user record
managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home
directory. The user account and home directory become the same concept.</para>
<para>The following backing storage mechanisms are supported:</para>
<itemizedlist>
<listitem><para>Individual LUKS2 encrypted loopback files for each user, located in
<filename>/home/*.home</filename>. At login the file systems contained in these files are mounted,
after the LUKS2 encrypted volume is attached. The user's password is identical to the encryption
<listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in
<filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after
the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption
passphrase of the LUKS2 volume. Access to data without preceeding user authentication is thus not
possible, not even for the systems administrator. This storage mechanism provides the strongest data
possible, even for the system administrator. This storage mechanism provides the strongest data
security and is thus recommended.</para></listitem>
<listitem><para>Similar, but the LUKS2 encrypted file system is located on regular block device, such
@ -61,7 +62,7 @@
<listitem><para>An encrypted directory using <literal>fscrypt</literal> on file systems that support it
(at the moment this is primarily <literal>ext4</literal>), located in
<filename>/home/*.homedir</filename>. This mechanism also provides encryption, but substantially
weaker than the two mechanisms described above, as most file system metadata is unprotected. Moreover
weaker than LUKS2, as most file system metadata is unprotected. Moreover
it currently does not support changing user passwords once the home directory has been
created.</para></listitem>
@ -97,7 +98,7 @@
<para>Home directories managed by <filename>systemd-homed.service</filename> are usually in one of two
states, or in a transition state between them: when <literal>active</literal> they are unlocked and
mounted, and thus accessible to the system and its programs; when <literal>inactive</literal> they are
not mounted and thus not accessible. Activation happens automatically at log-in of the user and usually
not mounted and thus not accessible. Activation happens automatically at login of the user and usually
can only complete after a password (or other authentication token) has been supplied. Deactivation
happens after the user fully logged out. A home directory remains active as long as the user is logged in
at least once, i.e. has at least one login session. When the user logs in a second time simultaneously
@ -155,10 +156,10 @@
user on another host. <option>-E</option> is equivalent to <option>-j --export-format=stripped</option>,
<option>-EE</option> to <option>-j --export-format=minimal</option>. Note that when replicating user
accounts user records acquired in <literal>stripped</literal> mode will retain the original
cryptographic signatures and thus may only modified when the private key to update them is available
on the destination machine. When replicating users in <literal>minimal</literal> mode the signature
is remove during the replication and thus it is implicitly signed with the key of the destination
machine and thus may be updated there without any private key replication.</para></listitem>
cryptographic signatures and thus may only be modified when the private key to update them is available
on the destination machine. When replicating users in <literal>minimal</literal> mode, the signature
is removed during the replication and thus the record will be implicitly signed with the key of the destination
machine and may be updated there without any private key replication.</para></listitem>
</varlistentry>
<xi:include href="user-system-options.xml" xpointer="host" />

View File

@ -47,11 +47,12 @@
<listitem><para>Takes a boolean argument. If true, the home directory of the user will be suspended
automatically during system suspend; if false it will remain active. Automatic suspending of the home
directory improves security substantially as secret key material is automatically removed from memory
before the system is put to sleep and must be re-acquired (by user re-authentication) when coming
back from suspend. It is recommended to set this parameter for all PAM applications that have support
for automatically re-authenticating via PAM on system resume. If multiple sessions of the same user
are open in parallel the user's home directory will be left unsuspended on system suspend as soon as
at least one of the sessions does not set this parameter. Defaults to off.</para></listitem>
before the system is put to sleep and must be re-acquired (through user re-authentication) when
coming back from suspend. It is recommended to set this parameter for all PAM applications that have
support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
same user are open in parallel the user's home directory will be left unsuspended on system suspend
as long as at least one of the sessions does not set this parameter. Defaults to
off.</para></listitem>
</varlistentry>
<varlistentry>

View File

@ -98,7 +98,7 @@ option('portabled', type : 'boolean',
description : 'install the systemd-portabled stack')
option('userdb', type : 'boolean',
description : 'install the systemd-userdbd stack')
option('homed', type : 'boolean',
option('homed', type : 'combo', choices : ['auto', 'true', 'false'],
description : 'install the systemd-homed stack')
option('networkd', type : 'boolean',
description : 'install the systemd-networkd stack')

View File

@ -1,4 +1,5 @@
src/core/org.freedesktop.systemd1.policy.in
src/home/org.freedesktop.home1.policy
src/hostname/org.freedesktop.hostname1.policy
src/import/org.freedesktop.import1.policy
src/locale/org.freedesktop.locale1.policy

View File

@ -547,7 +547,7 @@ msgid "Change Session"
msgstr "Changer de Session"
#: src/login/org.freedesktop.login1.policy:396
msgid "Authentication is required for changing the virtual terminal."
msgid "Authentication is required to change the virtual terminal."
msgstr "Authentification requise pour changer de terminal virtuel."
#: src/machine/org.freedesktop.machine1.policy:22

View File

@ -527,7 +527,7 @@ msgid "Change Session"
msgstr "Zmiana sesji"
#: src/login/org.freedesktop.login1.policy:396
msgid "Authentication is required for changing the virtual terminal."
msgid "Authentication is required to change the virtual terminal."
msgstr "Wymagane jest uwierzytelnienie, aby zmienić terminal wirtualny."
#: src/machine/org.freedesktop.machine1.policy:22

View File

@ -12,10 +12,10 @@
bool suitable_user_name(const char *name) {
/* Checks whether the specified name is suitable for management via homed. Note that our client side
* usually validate susing a simple valid_user_group_name(), while server side we are a bit more
* restrictive, so that we can change the rules server side without having to update things client
* side, too. */
/* Checks whether the specified name is suitable for management via homed. Note that client-side we
* usually validate with the simple valid_user_group_name(), while server-side we are a bit more
* restrictive, so that we can change the rules server-side without having to update things
* client-side too. */
if (!valid_user_group_name(name))
return false;

View File

@ -393,7 +393,7 @@
<action id="org.freedesktop.login1.chvt">
<description gettext-domain="systemd">Change Session</description>
<message gettext-domain="systemd">Authentication is required for changing the virtual terminal.</message>
<message gettext-domain="systemd">Authentication is required to change the virtual terminal.</message>
<defaults>
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>

View File

@ -1246,7 +1246,7 @@ static int userdb_thread_sockaddr(struct sockaddr_un *ret_sa, socklen_t *ret_sal
assert(ret_sa);
assert(ret_salen);
/* This calculates an AF_UNIX socket address in the abstract namespace whose existance works as an
/* This calculates an AF_UNIX socket address in the abstract namespace whose existence works as an
* indicator whether to emulate NSS records for complex user records that are also available via the
* varlink protocol. The name of the socket is picked in a way so that:
*