While I have my own reservations about the viability of this revolutionary approach, it also has some real and practical issues to deal with:
1. LUKS encryption is mandatory with homed. How is this supposed to work on old machines which will be too slow to encrypt by modern standards? One of the popular use cases of Linux has been making old machines work. Also, how will the less powerful Android devices work with this encryption once this functionality is ported to Android world?
2. SSH Connectivity. One of the obvious side effects of LUKS encryption (as this how-to-geek article has noticed) is that no user can connect through SSH/SFTP service remotely once that user logs off from the machine because all the ssh configuration will be encrypted along with the user's home directory. This is an obvious glitch and no solution has been offered till date.
3. Good bye, backwards compatibility. This approach totally changes how the user authentication takes place and directories are structured (/home is mounted from a separate loopback device in /home/$user.homedir for ex). This is obviously going to break compatibility for a lot of apps and will also need lots of testing and experiment to ensure that it works reliably. This seems like a lot of wasted efforts for little or zero gains.
Despite these obvious hiccups, distros like Ubuntu and Arch have lapped up systemd-homed and hurriedly included in their latest versions (the former even did it for the LTS version 20.04 which is much too worrying). Sometimes, it seems like some distros actively try to ruin the stability and predictability of their users' machines and eternally keep them in “beta testing“ mode.
1 comment:
1. is a straight up lie. systemd-homed supports unencrypted user directories either by the straight directories or as btrfs subvolumes via the --storage=directory or --storage=subvolume switch.
So the argument is nonsense.
2. There exist workaroungs for this via
AuthenticationMethods publickey,password
AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u
AuthorizedKeysCommandUser root
in your sshd_config and have both the key as well as the users password to unlock the home directory on the first ssh conenction.
Not 100% when this was introduced, so maby in July this was still a problem, today it is not.
3. I do not even have a clue what you are talking about. Once the user is logged in, everythign is still as it was 20 years ago. Either way, you will have a folder /home/user which is accessible as the user. In the apst, it might have been a mount, a straigt folder, or a symlinkt osomewhere else, with systemd-homed it is always a mounted loop back device to wahtever storage option you decided to go with, encrypted or not. How would that break any apps? They should be agnostic to that.
If you do not trust me, have a look at https://wiki.archlinux.org/index.php/Systemd-homed which has all the information above plus much more.
Post a Comment