picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Various typo fixes and grammar corrections

This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2020-01-30 13:46:19 +01:00
parent 402058dc3a
commit 2a4be3c52b
5 changed files with 29 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

31
man/homectl.xml
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" />

11
man/pam_systemd_home.xml
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>

8
src/home/home-util.c
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;

2
src/shared/userdb.c
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:
* *