Compare commits
8 Commits
4119d1e60a
...
4d2db005d8
Author | SHA1 | Date |
---|---|---|
Yu Watanabe | 4d2db005d8 | |
mtron | 58345a2332 | |
Piotr Drąg | 258adeca3c | |
mtron | 56b3eddb70 | |
mtron | e5e529c30a | |
Zbigniew Jędrzejewski-Szmek | 2a4be3c52b | |
Zbigniew Jędrzejewski-Szmek | 402058dc3a | |
Zbigniew Jędrzejewski-Szmek | ec74f47e56 |
4
TODO
4
TODO
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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" />
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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')
|
||||
|
|
|
@ -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
|
||||
|
|
2
po/fr.po
2
po/fr.po
|
@ -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
|
||||
|
|
2
po/pl.po
2
po/pl.po
|
@ -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
|
||||
|
|
|
@ -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;
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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:
|
||||
*
|
||||
|
|
Loading…
Reference in New Issue