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 janrinok on Friday May 01 2020, @12:44PM (17 children)
(Score: 4, Touché) by The Mighty Buzzard on Friday May 01 2020, @01:22PM (13 children)
A) My login/uid does exist on that computer if it's networked and using kerberos. Just like yours does on dev now that I got rid of the second entry for you that was confusing kerberos.
B) I've never had to deal with a situation where I needed my home directory wagged to an air-gapped computer but booting from the drive I'm already wagging along isn't an option.
My rights don't end where your fear begins.
(Score: 2) by janrinok on Friday May 01 2020, @01:36PM (7 children)
Only on that network.
How do you take a portable drive to a computer NOT on that network and have it install itself so that you still have ownership and access control over all of your files? What if your UID is already in use on that computer? Who would have ownership then? You, or the owner of that UID on the new computer?
(Score: 4, Insightful) by The Mighty Buzzard on Friday May 01 2020, @01:55PM (1 child)
How many admins do you know that want people without a login (either networked or local) having access to a box? It's certainly not an end user feature.
My rights don't end where your fear begins.
(Score: 3, Insightful) by sjames on Sunday May 03 2020, @10:37AM
And conversely, how often do you want documents important enough to encrypt to become accessible to a strange computer? If you're not willing to make your home directory world r/w and share it on a public network, you won't be too thrilled to plug it in on a strange computer.
(Score: 1, Informative) by Anonymous Coward on Friday May 01 2020, @09:12PM (3 children)
If you're root, it's not a problem. If you're not root, you can't mount the drive anyway.
(Score: 3, Informative) by janrinok on Saturday May 02 2020, @07:11AM (2 children)
(Score: 1, Insightful) by Anonymous Coward on Saturday May 02 2020, @12:54PM (1 child)
That's Ubuntu defaulting to unsecure, not surprising. None of my systems automount anything.
(Score: 3, Informative) by janrinok on Sunday May 03 2020, @07:11AM
So if a computer user wants to back up his user area to a thumbdrive or portable disk on your system does he need to go and find an administrator? That doesn't seem very sensible to me.
On ubuntu the drive is mounted with the same permissions as the user, so the system is still protected posing no more risk than that user has rights to do anyway..
(Score: 2, Interesting) by Anonymous Coward on Friday May 01 2020, @09:56PM
Let me introduce you to encrypted containers on NTFS or ExFAT. Portable. Secure. If you can mount it you can access it. Look into Veracrypt and it will solve your problem without fucking up everything for the rest of us.
(Score: 2) by janrinok on Friday May 01 2020, @01:39PM (4 children)
Saying that you don't have the need is not solving the problem for those that do. Just because you don't need it doesn't mean nobody else should need it either.
So I ask again - what is your kerberos and scripting solution, or any solution at all, to that problem?
(Score: 3, Insightful) by The Mighty Buzzard on Friday May 01 2020, @01:56PM (3 children)
That's kind of the point. It's a problem that does not exist.
My rights don't end where your fear begins.
(Score: 2, Informative) by janrinok on Friday May 01 2020, @02:51PM (2 children)
Not for you - but there are many who do have this problem.
(Score: 5, Touché) by The Mighty Buzzard on Friday May 01 2020, @03:25PM
Are there? In what situation would any admin want someone who specifically does not have a login (either networked or local) to a system not only able to log in but to bring arbitrary files along for the ride?
My rights don't end where your fear begins.
(Score: 2, Informative) by Anonymous Coward on Friday May 01 2020, @11:17PM
It doesn't exist for anybody. If people need to have their various IDs matching on different systems, there are multiple solutions to that already. If, you're logging into random computers where your UID and GID aren't matching, you're doing something very, very wrong. Modern systems have various ways in which they can keep UIDs and GIDs consitant across different computers. Try using one of them, they don't require the abomination that is systemd.
As has already been mentioned, Kerberos is a thing, you can also opt for mounting some or all of /etc over the network with a local backup as failsafe. Ultimately, The developer of this crappy software is either incompetent or an egomaniac. Or, probably both, none of the "problems" he's solving are real problems and they certainly don't require the kind of software kludge he's made.
(Score: 5, Interesting) by DECbot on Friday May 01 2020, @01:45PM (2 children)
Here's why some of the systemd haters will hate, take that portable disk and plug it into a system without systemd, will it work? Will systemd-homed work with other init systems? If not, it is a broken design that should not be on a linux box. What if kerberos must be used for technical reasons or if you are using a PAM/LDAP solution for managing password authentication, how would you access that drive? All of my servers are headless, ssh needs to be thought out, and putting those files outside the home directory just trades the shadow & password problem for a known_hosts & authorized_keys problem. Also, how do you manage per-machine group access? On your laptop you may be trusted with sudo, but on the file server, you're just a normal user. Where does that get managed?
There are smart ways of doing this. I am not confident the systemd group is the best one to address these because of the past management, interoperability, and portability of systemd. Yes SysV needed an overhaul that all the distros could rally around to improve the standardization of the linux ecosystem--however, like what happened with pulseaudio, I think they all bet on the wrong horse. Systemd-homed will further complicate what should be simple and easy.
cats~$ sudo chown -R us /home/base
(Score: 2) by janrinok on Friday May 01 2020, @02:50PM (1 child)
How do you manage that now? If you want to have full access to groups then you will need the assistance from an administrator of that computer - just as you would do today. But you could connect your own data and still have the appropriate user control over your own data. You wouldn't have to log on as an existing user of that computer who might not have the appropriate access permissions for your data, nor do they have to create a new user identity just so you can access your drive. It's not for everybody but nothing ever is.
I understand and accept your other points - you would have to solve them just as you do today. You probably wouldn't want to have random drives plugged into your secure network. But that would apply to any computer/laptop/device you wanted to plug in to that network. Have you tried plugging a LUKS encrypted drive into Windows? Doesn't work there either.
If someone has a better solution - I have to ask why they haven't produced it yet.
(Score: 0) by Anonymous Coward on Friday May 01 2020, @11:21PM
You load it over the network with group permissions being used for anything that the end user can reasonably expect to do without admin approval. This is the same sort of ignorance that was pushed for years about how great Active Directory was and how essential it was. But, even at the time, there were ways of making it work, it's just that it wasn't a single tool and required that you actually know what you were doing. You could load the relevant files in /etc over the top of the ones of the local install and address a bunch of the issues that people are talking about in this comment section.
Back then, it worked just fine, provided you knew what you were doing. And, if something wasn't working well, there were multiple ways of achieving the same thing.