diff --git a/TODO b/TODO index 35bd4b12b7e..bad3a7047b4 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 a2c4e4a2532..ae502c8ebbb 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 8b8890db766..72a6d091bfc 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 bf4f238099c..82c50a6b515 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 af2a1cc76fc..215e17db9b6 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: *