SoylentNews is people
SoylentNews
from the resistance-is-futile.-/home-will-be-assimilated dept.
Good News:
Linux home directory management is about to undergo major change:
With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.
[...] Prior to systemd every system and resource was managed by its own tool, which was clumsy and inefficient. Now? Controlling and managing systems on Linux is incredibly easy.
But one of the creators, Leannart Poettering, has always considered systemd to be incomplete. With the upcoming release of systemd 245, Poettering will take his system one step closer to completion. That step is by way of homed.
[...] let's take a look at the /home directory. This is a crucial directory in the Linux filesystem hierarchy, as it contains all user data and configurations. For some admins, this directory is so important, it is often placed on a separate partition or drive than the operating system. By doing this, user data is safe, even if the operating system were to implode.
However, the way /home is handled within the operating system makes migrating the /home directory not nearly as easy as it should be. Why? With the current iteration of systemd, user information (such as ID, full name, home directory, and shell) is stored in /etc/passwd and the password associated with that user is stored in /etc/shadow. The /etc/passwd file can be viewed by anyone, whereas /etc/shadow can only be viewed by those with admin or sudo privileges.
[...] Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. That record will contain all user information such as username, group membership, and password hashes.
Each user home directory will be linked as LUKS-encrypted containers, with the encryption directly coupled to user login. Once systemd-homed detects a user has logged in, the associated home directory is decrypted. Once that user logs out, the home directory is automatically encrypted.
[...] Of course, such a major change doesn't come without its share of caveats. In the case of systemd-homed, that caveat comes by way of SSH. If a systemd-homed home directory is encrypted until a user successfully logs in, how will users be able to log in to a remote machine with SSH?
The big problem with that is the .ssh directory (where SSH stores known_hosts and authorized_keys) would be inaccessible while the user's home directory is encrypted. Of course Poettering knows of this shortcoming. To date, all of the work done with systemd-homed has been with the standard authentication process. You can be sure that Poettering will come up with a solution that takes SSH into consideration.
Older articles:
- Pack Your Bags – Systemd Is Taking You To A New Home
- Systemd-Homed Merged As A Fundamental Change To Linux Home Directories
Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?
(Score: 2) by hendrikboom on Friday May 01 2020, @02:22PM (6 children)
I remember delaying upgrading my Debian system when the new release was a systemd release.
I hung on as my usual system became obsolete until I could upgrade to devuan.
-- hendrik
(Score: 1) by DECbot on Friday May 01 2020, @04:31PM (5 children)
Same here. I went from Wheezy --> Devuan Jessie --> Ascii with my webmail server rather recently. I have it on my laptop too. I wish there was more of an Ubuntu polish to everything, but nevertheless, I'm getting tempted to change my file server from FreeBSD to Devuan too. Getting around the GELI encryption will be interesting as all the data is on GELI encrypted ZFS partitions and I'm not about to buy additional drives to temporarily hold the data to reinstall nor will I upload 2TB of data to the cloud to redownload it 20 minutes later.
Okay. Conceptually, I grok that this shouldn't be a problem, but you've got to understand, I've really to need to rethink how I do backups.
cats~$ sudo chown -R us /home/base
(Score: 2) by hendrikboom on Friday May 01 2020, @05:26PM (1 child)
Yes. That's an issue.
Does Devuan handle that encryption system?
I did not encrypt my hard drives. For me, losing the decryption key is a bigger risk than leaking the data.
-- hendrik
(Score: 1) by DECbot on Friday May 01 2020, @07:10PM
So, the laptop was built back in the ZFS on Linux in the ZFS 6.9 era I believe, so encryption was done by LUKS. I've got the details of how I got that working in my journal. If I ever redo it, I'd try to use the baked in ZFS encryption now that it's released.
GELI is a whole other story as that is a BSD only thing. That was the way to do ZFS+encryption with BSD before ZFS had native encryption. There has been some toy applications on Github for decrypting Geli encrypted volumes on Linux, but nothing with robust testing. To safely get the data, I would either have to install Devuan on a new disk and run BSD in a virtual machine to serve the data or detach one encrypted partition from the zvol, format, and then reattach it to the zvol as a new, never been encrypted partition, and then after that resilver the zpool. Once the resilver is done, repeat that procedure for the other 3 drives. No matter how I decide to do it, I am very tempted to add two additional disks as some sort of mirror for holding the os, and leaving the data on the current zpool. What's nice about the ZFS native encryption is I can apply the encryption after the device creation, so I don't have to recreate my dataset. Here's the info: ZFS encryption preview [heckel.io]. Note, this blog dates back to 2017 where as ZFS encryption just landed as stable some time last year if I'm recalling things correctly.
cats~$ sudo chown -R us /home/base
(Score: 2) by janrinok on Friday May 01 2020, @06:25PM (2 children)
Unfortunately, I think (but I am not certain) that the GELI and LUKS systems are only workable on BSD and Linux systems respectively. I looked at moving several systems to BSD a year or two back, but as all my data in on encrypted drives (18 in total over 7 computers with individual backups) the task became unworkable. Data from a LUKS drive couldn't be easily transferred to a BSD system - well I could have sent it all across the network but that didn't seem like a good idea for 36TB of data. I didn't specifically look at moving the data back the other way.
(Score: 1) by DECbot on Friday May 01 2020, @08:28PM (1 child)
Theoretically, you could run a Linux VM on the BSD host to unlock the LUKS container, which is what I was thing of doing but in the reverse (BSD VM to unlock GELI container on Linux host). When I have the time and the cojones to try it, since this is a ZFS dataset with redundancy on four GELI containers, I could decouple the drives one at a time from the zpool and re-add them to the zpool without the encryption layer. The procedure should be the same as when I replaced all the 1TB drives with 3TB drives to increase capacity. Once the data is decrypted, installing a linux on a different drive and mounting the ZFS zpool should be cake. If I had the capacity on a different disk, I could zfs-send the data over, do the install, and then send it back.
That might be somehting you could try. Boot into Linux & unlock the LUKS containers, ZFS-send the data to an unencrypted intermediary disk, install BSD, create GELI encrypted partition, use the unlocked GELI partition to create a zpool, and then zfs-send the data to the zpool encrypted by GELI. I would give it a go myself if I had a few hundred extra bucks to spend on drives.
cats~$ sudo chown -R us /home/base
(Score: 2) by janrinok on Friday May 01 2020, @08:45PM