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 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 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 absence of other partitions for trusted boot environments
* systemd-repart: when no configuration is found, exit early do not check * 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 username prefix searches in varlink API
* userdb: allow existance checks * userdb: allow existence checks
* pid: activation by journal search expression * 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 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 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 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 sorted alphabetically by their key) before storing it there, though this is not
required nor enforced. Since the user record is cryptographically signed the 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 4. Default parameters for backup applications and similar
Similar to JSON User Records there are also [JSON Group 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 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 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? ## 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 the fields included therein are only useful when executing authentication
operations natively against JSON user records. 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 purposes. Inside the home directories (and if the LUKS2 backend is used, also
in the LUKS2 header) a user record containing the `regular`, `privileged`, in the LUKS2 header) a user record containing the `regular`, `privileged`,
`perMachine` and `signature` sections is stored. `systemd-homed` also stores a `perMachine` and `signature` sections is stored. `systemd-homed` also stores a

View File

@ -39,18 +39,19 @@
which manages home directories of users.</para> which manages home directories of users.</para>
<para>Home directories managed by <filename>systemd-homed.service</filename> are self-contained, and thus <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 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 in itself describes a matching user record, and every between machines. In particular, a home directory describes a matching user record, and every user record
user record managed by <filename>systemd-homed.service</filename> also implies existance and managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home
encapsulation of a home directory. The user account and home directory hence become the same concept. The directory. The user account and home directory become the same concept.</para>
following backing storage mechanisms are supported:</para>
<para>The following backing storage mechanisms are supported:</para>
<itemizedlist> <itemizedlist>
<listitem><para>Individual LUKS2 encrypted loopback files for each user, located in <listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in
<filename>/home/*.home</filename>. At login the file systems contained in these files are mounted, <filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after
after the LUKS2 encrypted volume is attached. The user's password is identical to the encryption 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 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> security and is thus recommended.</para></listitem>
<listitem><para>Similar, but the LUKS2 encrypted file system is located on regular block device, such <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 <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 (at the moment this is primarily <literal>ext4</literal>), located in
<filename>/home/*.homedir</filename>. This mechanism also provides encryption, but substantially <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 it currently does not support changing user passwords once the home directory has been
created.</para></listitem> created.</para></listitem>
@ -97,7 +98,7 @@
<para>Home directories managed by <filename>systemd-homed.service</filename> are usually in one of two <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 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 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 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 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 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>, 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 <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 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 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 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 is removed during the replication and thus the record will be implicitly signed with the key of the destination
machine and thus may be updated there without any private key replication.</para></listitem> machine and may be updated there without any private key replication.</para></listitem>
</varlistentry> </varlistentry>
<xi:include href="user-system-options.xml" xpointer="host" /> <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 <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 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 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 before the system is put to sleep and must be re-acquired (through user re-authentication) when
back from suspend. It is recommended to set this parameter for all PAM applications that have support coming back from suspend. It is recommended to set this parameter for all PAM applications that have
for automatically re-authenticating via PAM on system resume. If multiple sessions of the same user support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
are open in parallel the user's home directory will be left unsuspended on system suspend as soon as same user are open in parallel the user's home directory will be left unsuspended on system suspend
at least one of the sessions does not set this parameter. Defaults to off.</para></listitem> as long as at least one of the sessions does not set this parameter. Defaults to
off.</para></listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>

View File

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

View File

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

View File

@ -547,7 +547,7 @@ msgid "Change Session"
msgstr "Changer de Session" msgstr "Changer de Session"
#: src/login/org.freedesktop.login1.policy:396 #: 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." msgstr "Authentification requise pour changer de terminal virtuel."
#: src/machine/org.freedesktop.machine1.policy:22 #: src/machine/org.freedesktop.machine1.policy:22

View File

@ -527,7 +527,7 @@ msgid "Change Session"
msgstr "Zmiana sesji" msgstr "Zmiana sesji"
#: src/login/org.freedesktop.login1.policy:396 #: 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." msgstr "Wymagane jest uwierzytelnienie, aby zmienić terminal wirtualny."
#: src/machine/org.freedesktop.machine1.policy:22 #: src/machine/org.freedesktop.machine1.policy:22

View File

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

View File

@ -393,7 +393,7 @@
<action id="org.freedesktop.login1.chvt"> <action id="org.freedesktop.login1.chvt">
<description gettext-domain="systemd">Change Session</description> <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> <defaults>
<allow_any>auth_admin_keep</allow_any> <allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive> <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_sa);
assert(ret_salen); 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 * 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: * varlink protocol. The name of the socket is picked in a way so that:
* *