In previous Linux, adding users was done with ʻuseradd, home directories were created as directories under / home, and user accounts were / etc / passwd, / etc / group, . It was managed in / etc / shadow`.
From now on, systemd-homed will replace all that work.
A user management daemon added in systemd version 245. The entity is a systemd service unit file, launched as systemd-homed.service.
~~ It seems that user management and authentication will be done by systemd-homed (hereinafter, homed) in the future. ~~ I corrected it because there was no source and it was a mistake. Whether to use systemd-homed is a user choice, so there is no need to force a migration. homed itself is automatically enabled if you have the latest systemd installed. (However, it is necessary to set it in order to use it. It will be described later.)
--Create, delete, edit users
--Management of user information by JSON file for each user, which changes to / etc / passwd, / etc / group, / etc / shadow
--Encryption / decryption of home directory
--Giving nosuid, nodev, noexec to your home directory
--Limitation of user resources
I will explain only the above three one by one.
When managing users with homed, you should use the homectl command instead of commands such as ʻuseradd. ** Of course, please be assured that you can continue to manage users using ʻuseradd and / etc / passwd on Linux with homed installed. ** However, the account created on one side cannot be managed by the other side. (Incompatible)
Also, since homed supports NSS (systemd is added to nsswitch.conf), Linux users can be recognized correctly even with the getent command and conventional software using glibc.
Let's take a brief look at the new homectl command.
--homectl create <user> Add user
--homectl remove <user> Remove user
--homectl update <user> User update
--homectl passwd <user> Change user password
The options that can be specified / changed by create and update are as follows. * There are many more, but they are omitted because they are long. For more information, go to homectl -h.
General User Record Properties:
-c --real-name=REALNAME Real name for user
--realm=REALM Realm to create user in
--email-address=EMAIL Email address for user
--location=LOCATION Set location of user on earth
--icon-name=NAME Icon name for user
-d --home-dir=PATH Home directory
--uid=UID Numeric UID for user
-G --member-of=GROUP Add user to group
--skel=PATH Skeleton directory to use
--shell=PATH Shell for account
--setenv=VARIABLE=VALUE Set an environment variable at log-in
--timezone=TIMEZONE Set a time-zone
--language=LOCALE Set preferred language
--ssh-authorized-keys=KEYS
Specify SSH public keys
--pkcs11-token-uri=URI URI to PKCS#11 security token containing
private key and matching X.509 certificate
Account Management User Record Properties:
--locked=BOOL Set locked account state
--not-before=TIMESTAMP Do not allow logins before
--not-after=TIMESTAMP Do not allow logins after
--rate-limit-interval=SECS
Login rate-limit interval in seconds
--rate-limit-burst=NUMBER
Login rate-limit attempts per interval
Password Policy User Record Properties:
--password-hint=HINT Set Password hint
--enforce-password-policy=BOOL
Control whether to enforce system's password
policy for this user
-P Equivalent to --enforce-password-password=no
--password-change-now=BOOL
Require the password to be changed on next login
--password-change-min=TIME
Require minimum time between password changes
--password-change-max=TIME
Require maximum time between password changes
--password-change-warn=TIME
How much time to warn before password expiry
--password-change-inactive=TIME
How much time to block password after expiry
Resource Management User Record Properties:
--disk-size=BYTES Size to assign the user on disk
--access-mode=MODE User home directory access mode
--umask=MODE Umask for user when logging in
--nice=NICE Nice level for user
--rlimit=LIMIT=VALUE[:VALUE]
Set resource limits
--tasks-max=MAX Set maximum number of per-user tasks
--memory-high=BYTES Set high memory threshold in bytes
--memory-max=BYTES Set maximum memory limit
--cpu-weight=WEIGHT Set CPU weight
--io-weight=WEIGHT Set IO weight
You can see that various resource restrictions can be added in addition to the options that can be specified with useradd so far.
Another important point is that the password expiration date can be set for each user, and the number of login attempts per fixed time can be limited here.
homed also manages user information. Users created by homectl will not be listed in / etc / passwd, / etc / group, / etc / shadow.
Instead,
--User information is managed by the homed daemon and provided by API. (Probably the /run/systemd/userdb/io.systemd.Home socket)
--In addition, a file called ~ / .identity is created in each home directory, and you can check the user information in JSON format.
~ / .identity is, for example, something like this.
{
"cpuWeight" : 10,
"disposition" : "regular",
"lastChangeUSec" : 1584387192577240,
"lastPasswordChangeUSec" : 1584382416144118,
"memberOf" : [
"testgroup"
],
"perMachine" : [
{
"diskSize" : 10737418240,
"matchMachineId" : [
"48801054a2af8b2c0104ff82c482fe2d"
]
}
],
"privileged" : {
"hashedPassword" : [
"$6$h9kNT.dmjmHXt/i1$ATJy/KnBCXMlmIjBziemYqRa8XUtiVDMCnC.m/iSNNh8zdXfX5V7jJwwsZCJo3PJIv3.C0p/6OXTxN8CXCIcS1"
]
},
"signature" : [
{
"data" : "hoge",
"key" : "-----BEGIN PUBLIC KEY-----\fuga=\n-----END PUBLIC KEY-----\n"
}
],
"userName" : "test"
}
This file can be read and written by non-root, so it's likely that the body is somewhere else, or that homed has signed this file with the signature item. But I don't know if both are my speculations.
userdbctl
If you want to check user information and group information other than creating / updating users, use the ʻuserdbctl` command.
Subcommand
user [USER…] Inspect user
group [GROUP…] Inspect group
users-in-group [GROUP…] Show users that are members of specified group(s)
groups-of-user [USER…] Show groups the specified user(s) is a member of
For example, ʻuserdbctl user
It is PAM (Pluggable Authentication Modules) that manages Linux users. Let's talk about pam.
--The substance of PAM is just a configuration file and a shared library (PAM module). --The role of PAM is to verify the user's credentials when the login prompt or sshd gets the user's information at login. ――Specifically, each login software executes a shared library (PAM module) that fetches the password from the TTY and returns success if it is correct. --Each software runs the default shell for that user when success comes back.
In a traditional environment without homed, there is a "PAM module that reads / etc / passwd and / etc / shadow and returns success to the software if the password is correct", and uses it by default. It was a configuration file. (Details omitted)
In the homed era, we will add ** a "PAM module that calls homed to check the user's credentials" to this pam. ** Because it is an addition, the existing user management will also be applied.
By the way, as an aside, I also added a module to this PAM when managing the network of Linux users such as LDAP authentication and NIS authentication.
** * If you do not make this setting, you will not be able to log in even if you add a user with homectl. ** **
In order to use homed, you need to prepare for the time being. You need to update the pam config file. Probably, if you install the OS with the latest systemd, the updated configuration file will be included by default, but we need to manually rewrite the configuration file when updating in the middle. This is speculation, but it's probably because the pam config file is pretty much edited after installation depending on the environment (for LDAP authentication, etc.).
If you haven't messed with the pam settings, you can overwrite the pam settings and the update is complete.
$ sudo cp /usr/share/factory/etc/pam.d/system-auth /etc/pam.d/system-auth
If you're playing around with the settings, look at the diff and set it to your liking. You can check the detailed setting method by executing man pam_systemd_home.
Perhaps the biggest feature of homed is that it supports home directory encryption. Until now, it was necessary to set each one with ecryptfs etc.
homed allows you to choose the type of home directory when you create a user. (--storage =)
** If nothing is specified, homed will use luks by default. ** **
--directory… As usual, create a directory with your user name under / home
--subvolume… Create btrfs subvolume of user name under / home
--Create a home directory using LUKS encryption under luks… / home
--fscrypt… I used FSCrypt under / home (abbreviation)
--cifs… / home, using cifs (so-called Samba / network sharing) (abbreviation
Of these, use luks or fscrypt to encrypt. Well, it's natural because it uses LUKS and FS Crpyt. Unless you have a specific reason, systemd recommends using luks over fscrypt.
In addition, this homed luks encryption supports automatic decryption and automatic re-encryption at user login / logout. It's convenient.
luks in homed (bonus)When using luks with homed, a file with a size of several tens of GB called username.home is generated under/ home /. This is apparently the body of the home directory.
This file is an image file of ʻext4 or btrfs(you can choose which file system to use inside luks), and this is encrypted with luks (dm-verity) together with the block storage. homed seems to mount this image file to/ home / username` while decrypting it at login.
Use the homectl command to decrypt (mount) the home directory when the user is not logged in. Of course, a decryption passphrase (similar to the user's login password) is required for decryption.
--homectl activate <user> decrypt
--homectl deactivate <user> encryption
Apparently, the decrypted state is called "active". By the way, you can check which user is currently active with homectl list.
What you notice here is that you need a decryption passphrase to access the user's home directory. Even if you have root privileges, it is a great security and privacy advantage that you cannot access someone else's home directory unless the user is logged in (undecrypted by the user).
Users created with homectl seem to be limited in size of their home directory by default. In the case of luks, the size of the image file is limited.
You can use the homectl resize command to change the size limit.
Example:
$ homectl resize user1 10G
Since the image file in luks mode is a fixed image file (a method of securing space in advance), several tens of GB of empty image files are created from the beginning. It's inefficient and I don't use it that much, so I think it's a good idea to keep it to about 10GB with the resize command.
Introduced systemd-homed. You can continue to manage users using the conventional method. Therefore, if there is no problem in the current situation, it will take a long time for homed to gradually penetrate. However, it is very convenient for Linux desktop users, so if you are interested, please use it.
Excuse me for the long sentence & thank you for reading this far.
Recommended Posts