diff --git a/TODO b/TODO
index 35bd4b12b7..bad3a7047b 100644
--- a/TODO
+++ b/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
diff --git a/man/homectl.xml b/man/homectl.xml
index a2c4e4a253..ae502c8ebb 100644
--- a/man/homectl.xml
+++ b/man/homectl.xml
@@ -39,18 +39,19 @@
which manages home directories of users.
Home directories managed by systemd-homed.service 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 systemd-homed.service 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:
+ 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 systemd-homed.service also implies existence and encapsulation of a home
+ directory. The user account and home directory become the same concept.
+
+ The following backing storage mechanisms are supported:
- Individual LUKS2 encrypted loopback files for each user, located in
- /home/*.home. 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
+ An individual LUKS2 encrypted loopback file for a user, stored in
+ /home/*.home. 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.Similar, but the LUKS2 encrypted file system is located on regular block device, such
@@ -61,7 +62,7 @@
An encrypted directory using fscrypt on file systems that support it
(at the moment this is primarily ext4), located in
/home/*.homedir. 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.
@@ -97,7 +98,7 @@
Home directories managed by systemd-homed.service are usually in one of two
states, or in a transition state between them: when active they are unlocked and
mounted, and thus accessible to the system and its programs; when inactive 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. is equivalent to ,
to . Note that when replicating user
accounts user records acquired in stripped 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 minimal 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.
+ 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 minimal 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.
diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml
index 8b8890db76..72a6d091bf 100644
--- a/man/pam_systemd_home.xml
+++ b/man/pam_systemd_home.xml
@@ -47,11 +47,12 @@
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.
+ 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.
diff --git a/src/home/home-util.c b/src/home/home-util.c
index bf4f238099..82c50a6b51 100644
--- a/src/home/home-util.c
+++ b/src/home/home-util.c
@@ -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;
diff --git a/src/shared/userdb.c b/src/shared/userdb.c
index af2a1cc76f..215e17db9b 100644
--- a/src/shared/userdb.c
+++ b/src/shared/userdb.c
@@ -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:
*