Hacker News Reader

> Who actually has multi-user systems. Really has them.

In other words, you personally don't use multi-user systems, and somehow you interpret that as no one having the need for multi-user systems. Does that make any sense?

Speaking for myself, if multiseat Linux boxes were more easy to setup, I would certainly use one of those as my family's primary desktop. Today's desktop systems are quite capable of taking a multi-user computational beating and breeze through any amount of browser windows opened. Thus, if buying a monitor and keyboard is all it takes to get another computer seat then why not?

> a monitor and keyboard

And a Raspberry Pi.

Nope, you plug multiple monitors and peripherals into the multiseat box. Terminal(emulator)s are only used over long distances.

Plugging in an underpowered and resource-starved raspberry pi doesn't give you the same user experience as plugging in a Ryzen7 with 32GB of RAM that you already paid for and have lying around and idling at 5%

I guess people have different ideas about what a thin terminal means.

You're the one confusing a thin terminal with a multi-seat system. This thread is discussing multi-user and multi-seat systems and thin clients is a whole different beast.

Not really. A thin client is just another way to add a seat to a multiuser machine. Thin clients are just fine for a lot of real work (programming, office tasks). But for home use you need clean 1080p fullscreen video playback and none of the traditional thin clients can handle that.

systemd supposedly has built-in plug-and-play multiseat support: http://0pointer.de/blog/projects/multi-seat.html

Not sure I've heard of people using it, but I'm curious!

I use it. It works. I lucked into a semi-obsolete high-end gamer machine with a 6-core i7 and 24GB of memory and three full-length PCI-Express slots. I leave my machine on. The standby power of this monster (850W power supply) was too high to justify. So I tried it. Three video cards in the three slots. Came right up, the Linux desktop extended seamlessly across any monitor plugged into any of the cards (a mix of AMD and Nvidia no less).

Enter multi-seat. A few "sticky" commands later (i.e. only needed for reconfiguration, not on every boot) I have three user stations, each with monitor, keyboard, mouse, audio and at least one dedicated USB socket. Works a treat. It's not 100% bulletproof; crashes to the point of needing a reboot maybe 2-3 times a year, but aside from that indistinguishable from dedicated computers for each screen.

Stock Fedora 28. Here's the sum total of commands needed to set up the multiseat in my setup (seat 0 gets everything not assigned to the others).

loginctl attach seat1 /sys/devices/pci0000:00/0000:00:09.0/0000:05:00.0/drm/card0 /sys/devices/pci0000:00/0000:00:09.0/0000:05:00.0/graphics/fb0 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5 loginctl attach seat2 /sys/devices/pci0000:00/0000:00:07.0/0000:04:00.0/drm/card2 /sys/devices/pci0000:00/0000:00:07.0/0000:04:00.0/graphics/fb2 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3 loginctl attach seat2 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.1/1-4.1.4/1-4.1.4:1.2/0003:046D:C52B.00A3/0003:046D:4004.00A4/input/input194 loginctl attach seat2 /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4.4/1-4.4:1.0/0003:045E:00B9.00A5/input/input195

I hope this functionality doesn't turn into abandonware before I'm done with this monster machine i.e. it breaks or becomes too obsolete. I did in the past try to set up multiseat, just for fun, with a Displaylink box, after reading the article about it, but got nowhere, with the distinct feeling that they got it working once, and then abandoned it.

A few more details. One thing that doesn't work very well is storage devices. For one thing, as soon as one appears, the (non-multiseat aware) file managers all jump on it and try to mount it. And two of the three get a password prompt because they don't own the USB socket, and tie up the device so the one that does can't mount it. Solution: Turn off automount, and only use storage devices from seat 0.

You run into occasional other "more than one user per computer" issues. For example, trying to access the same UDP RTSP camera from VLC on two different desktops.

And the three desktops do get actively used by three differerent family members. Linux on the desktop for non-geeks/kids? Nobody cares. As long as the browser works with full video capability (smooth 1080p Youtube) and, in the child's case, the Tuxpaint painting program, everybody happy.

I keep thinking of more stuff to add. Multiple monitors: Well, a typical video card has two output sockets and easily drives two monitors. So why not two users? Because multiseat only works if each session gets to own its video chip, in its own private instance of Xorg or Wayland. There are hacks to split it by overlaying nested servers onto the one that owns the chip, but they have awful video performance (I tried it).

So you do need the multiple video cards (and slots to put them into). One per user. And even more idle power consumption. But the 124W that the machine now sucks down 24/7 is sort of justifiable in that it serves the whole family's browsing/computing needs aside from a few smartphone type gadgets. And the setup is physically robust, in a household with small children, in a way that laptops just aren't.

Cheap 7m HDMI cables and active USB extension cables (from Ali Express) take care of the physical separation between stations.

Sound is easy as long as you get it over HDMI - no need to configure a separate device, it comes with the video. But one of the stations owns the physical audio sockets on the motherboard, and one, for reasons too complicated to get into here, uses network audio over another Lennart special -Pulseaudio. That has its own frustrations, but the remote audio, once I got it working, has been solid.

Thanks for the detailed reply!

Also, are you using wired networking for remote audio? Last time I tried PulseAudio remote audio over wifi it instantly made wifi useless for everyone in the house. (Honestly I wouldn't mind mildly lossy compression, but there doesn't seem to be support for that.)

Wired, of course. Though I did accidentally configure the sending instance of PA to send multicast pakcets. Which it did, with abandon, even when no audio was playing, saturating the wifi to such an extent that I was driven to despair before I figured it out. Consumer grade Wifi gear, even if loaded with, say, OpenWRT, does not handle overload gracefully. PA configuration is a confusing mix of config files and GUI stuff.

> In other words, you personally don't use multi-user systems, and somehow you interpret that as no one having the need for multi-user systems. Does that make any sense?

No need for personal attacks.

I note that you opted to ridicule instead of answering, which I find unnecessary.

I'm not a systemd fan by any means, but yes, there are far more ways Linux is used where this will be useful. There are still compute clusters and terminal servers where the overhead and isolation of a VM is counterproductive, and use cases where containers are not yet secure enough.

I also think it's likely there are future solutions which will be made possible that we can't even imagine right now, through what this brings to the table.

But in these clusters where a VM is too much overhead, isn't LUKS and the others?

I manage huge compute clusters, with and without VMs, and can't imagine a feasible use case for this, barring a time machine to the 90s.

> But in these clusters where a VM is too much overhead, isn't LUKS and the others?

No. First of all, in general disk encryption is orthogonal to multi-user or multi-seat systems, and the same case for disk encryption can be made wrt VM sessions. Secondly, the main feature is migratable and self-contained home directories, which is also relevant for VMs (or even more relevant).

Hmm... migratable and self-contained home directories. What do you mean? iSCSI, or something like it? Again, I'm not seeing what value systemd is adding here.

They're rampant in the education industry - At basically every level.

School labs with many shared computers for kids high school aged and below.

Larger servers at colleges for projects that are just unreasonable to run on a standard desktop machine.

I'm out of date here, but in my days this was often AFS and stuff.

But again: What's the threat model for LUKS, here? A student has their stuff on that exact shared machine in the computer lab, and somehow local root attacks only work when attacker is alone on the machine?

Anecdotally, my laptop is being used by two users. It irks very much that neither Ubuntu nor Fedora can easily support a common directory for data to be shared between users. I ve created custom bash commands to fix group file ownership and similar issues arising from sharing a directory between two home users.

Have you looked into ACLs and/or setgid with a shared group? Used to do this at work all the time for numerous groups of users. This is definitely possible. You may need to pay attention to your umask.

I have not looked at ACLs. They look too complex. Setgid works on file copy but not on file move. Not sure about umask.

Well, move on ext4 (and most other Linux filesystems) has very specific semantics - keep the file intact in every possible way (including permissions, modification time, ownership etc) but make it visible through another name.

Please be aware that that the common semantics are that permissions are associated with a file, not with its name (and a file may have a lot of names through hard links, or no name at all - open a file, delete it, and it is only accessible if you have an fd, or with little more work through the inode number)

I am indeed on ext4 (and MATE DE). Thank you for the information, although I am not sure what's the next step to have the OS enforce a certain group (and 775 permissions optimally) on all files created/copied/moved (moved is the part that's the biggest pain) within a certain directory.

You can write a script that does "inotify_wait" on your directory and changes the permission on anything that's there and doesn't have them.

a share command that does the necessary permission changes (and optionally the move) would be nice.

effectively you want to be able to say: share this file with joe, or

    share -rw joe john ... file ... destination/;

something along those lines that will change the acl as needed.

You should be able to share a FAT32 partition without overwhelming permission problems.

Not much differently than sharing a USB volume.

It should be easy to do this? Create a group, place the two users in that group, create a directory and setgid it to the group.

That works when copying but not when moving files. For the latter case you need to manually edit those properties.

Just setup a third user ("adduser [--disabled-login] user3", then share his home directory: make both users members of the third user's main group "adduser user1 user3 && adduser user2 user3" (assuming you don't want to alter both user's main groups for privacy), then "chmod g+wx /home/user3" and have a cron job enforcing all files in the shared directory belong to the user3 user/group and are writable by the group "* * * * * root chown -r user3:user3 /home/user3 [possibly add: && false || chmod -r g+w /home/user3]". Then create (soft|hard) links to the third user's home dir if you like.

This way you retain each user's privacy, since main groups aren't changed, don't need to run custom scripts each time, and don't have multiple copies of the shared files. The only (IMHO minor) issue would be that newly shared files might only be accessible for the other user 30s later on average, and 1 minute at most. The cron job might be converted into a daemon monitoring new files appearing in /home/user3, but that is left as an exercise for the reader :)

You don't need to use groups since ACLs:

    setfacl -R \
    -m d:u:user1:rwx -m u:user1:rwx \
    -m d:u:user2:rwx -m u:user2:rwx \
    /home/shared

d:u: sets the default user ACL for future directory entries

u: sets the current user ACL for existing directory entries

-R sets the ACLs recursively on existing files

Plenty of places still have homes on NFS shared amongst all their machines. It is very handy. It means you can use any computers and still have all your files.

The fact that you are unfamiliar with a use case doesn't mean it doesn't exist.

> Plenty of places still have homes on NFS shared amongst all their machines.

Oh, I agree! That's my point. So what is systemd trying to solve?

Well, modern Android devices for one - they support multiple users, including quest accounts. So I guess they could use this instead of their (likely horrendous as it's Android) implementation.

Still, the main aim of this is in my opinion not safe isolation of users on a single machine, but rather safe locking of the encrypted root folder.

With a normal LUKS setup, everything is inside a LUKS container, including the rootfs from which the OS itself is running. This complicates locking the LUKS container when the device gets suspended, as there will be open files, etc.

With Homed as far as I can tell, this is explicitly possible, it should be able to drop the encryption keys when machine goes to suspend, making it less likely your data will be recovered if the machine gets lost or stolen. With the keys in RAM an attacker might attempt to pull it from the machine & read the keys or use some method to defeat the lockscreen. With the keys dumped from RAM, this is no longer possible.

Android is so hugely different that it's not really an argument for adding it to systemd.

> [locking when suspenden] With Homed as far as I can tell, this is explicitly possible

Is it? Your home dir definitely will have open files when you lock or suspend.

> The go-luks-suspend program replaces the default suspend mechanism of systemd. It chroots to initramfs in order to perform the luksSuspend, suspend to RAM, and luksResume operations. It relies on the shutdown initcpio hook to provide access to the initramfs.

https://github.com/guns/go-luks-suspend from 2013

This also doesn't accidentally leak all the stuff not within /home/you

Bay area large (not huge) corp dev here.

We do. We have like a dozen shared, beefy shell servers (varies, but think ~32 core not too old Xeon, ~256GB RAM, 1G or 10G stable network that's local to the office, TB's of storage and essentially unlimited on NFS) for devs (and more of the same dedicated for CI/CD).

We need this because the codebases are huge and take hours to build on a laptop (and copying across a home uplink would take forever too).

Homedirs are NFS mounted.

It's more cost efficient than spinning up an AWS/Azure instance for myself, and more limited resource efficient than spinning up a VM in OpenStack (both of which I do when appropriate). And it's very convenient team work wise.

There are (many, some avoidable but hard to fix by now) downsides for sure, but I cannot imagine doing this work solely on a laptop.

At least one huge Bay Area elephant used to run NFS home dirs for basically all their corp.

So do you run fscrypt or LUKS with that?

Because NFS was already possible, so what is systemd trying to solve?

One of the supposed benefits I remember from his original talk on systemd-homed is better handling of encrypted home directories even for a single user workstation.

Even on a single user workstation, having an encrypted root filesystem doesn't do as much good if your laptop is left booted up with the root filesystem unlocked most of the time. Systemd-homed in that scenario is supposed to make it easier to automatically unmount/mount on locking/unlocking the workstation.

Full disk encryption is the only reasonable solution and it already works with suspend

> Who actually has multi-user systems. Really has them.

systemd-homed isn't about multi-user systems, it's about multi-system users.

Goal #1: Migratable Home Directories (all the way to the point of "home-on-a-stick") https://cfp.all-systems-go.io/media/homed-asg2019.pdf

I want to take my home with me across all my systems, and /don't/ want network sync to do it with.

Use all the time for hobby website. It’s through Pair.com. BSD though, not Linux. It’s very inexpensive and a lot cheaper and easier than me setting up and maintaining a whole virtual box.

encrypted home directories?

Is that a question? I think you missed the point on this one.

> > Does it actually solve a problem?

> encrypted home directories?

This is something that isn't widely available on personal systems that would be supported by this change.

I should note I think the idea of systemd is valid, but I am not a fan of the implementation. (binary log files? disorganized configuration directories?)

All my workstations/laptops (at home and at work) have encrypted root filesystem, which includes /home.

So… this has not been a problem for 99%+ of users for like 20 years.

I do like the idea of some parts of systemd. Like structured logging. I'm so sick of every single tool having its own logging format. Some multi line, some not. Some using UTC, some not. Some making up their own BS date format, etc…