Hacker News Reader

Comment by armada651 | Hacker News Reader

Good security doesn't prevent users from executing a legitimate use case though. A user can have legitimate reasons for wanting to share a certain window or their entire screen with a process like Zoom. Once you start preventing users from executing their use case you turn the user into an adversary. They'll start undermining your security model and you will always lose that fight.

This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.

View on HN

> Once you start preventing users from executing their use case you turn the user into an adversary.

I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it.

(I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)

They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.

Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.

Really?

Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.

From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it.

Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?

I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems.

Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.

> From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it.

Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right?

This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly.

Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.

Please check out my sibling comment on this thread.

> From a theoretical view, why is it a bad thing?

Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed.

> Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?

Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes.

> I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks

It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone.

I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes?

> But these are trivially portable

OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working.

> some manageable breaking changes instead.

This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case.

They didn't think and things broke. You don't get to paint that as innovation.

Sighup already does this by default. You have tools like nohup and tmux that explicitly (as in, you won't do it accidentally) get around this and systemd breaks those. What bit me last time was running apt upgrade in tmux (I always do this so it doesn't get killed) and I came back to find that apt had been killed.

There wasn't any good reason to change this.

>hur dur why depend on evil systemd

Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though.

And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."

No, nohup and tmux are not explicit at all, they simply ignore the signal. The OS has no way of knowing whether it is a frozen process, or one that wants to run in the background.

If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them.

I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.

If you don't install a signal handler the process gets killed frozen or not. The only reason you would ever handle the hup signal is if you want exactly this behavior (user deciding when to terminate the process rather than the OS.) Give me one singular example where this isn't the case.

>I recommend

No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows.

>That's on them

No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."

What if the program does install a signal handler, but it has a race condition and enters an infinite loop? What situation does that correspond to from the POV of the OS?

Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.

>What if it crashes

If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for handling it in an interactive program is because you want that program to persist when the tty goes away and almost the only things that do this are tools like nohup and tmux, not the processes that run inside them) then your crashed program is going to be killed by the hup signal when the user closes their terminal.

Yes you can contrive pathological examples, yes signals are hacky in general. You're never going to be able to come up with a real problem with this other than "misusing tmux and nohup to manage deamons instead of initd causes problems." There isn't a legitimate problem with handling the hup signal for interactive tools when the user is expecting it.

>RE: Discerning between states

Yeah if you want the OS to manage a process for you write a service. I'm not going to write a service for everything I do interactively that needs to not die if there's a network problem.

Again, because you seem to be missing it, handling the hup signal in an interactive program is just a way to tell the OS that the user is managing the program themselves. If the user does this and then decides not to manage it, "that's on them."

And finally, the real problem here is that systemd breaks stuff like this all the time and makes the platform unpredictable unless you spend time reading the release notes.

Wayland doesn't prevent anything that people need, but the APIs are different and apps need to be ported. (Worst case, certain features need to be implemented in the compositor itself not in an app.)

Yeah. The most of the screen sharing and recording issues are easily solvable. It just takes engineering time, and time is money. As from the global user space, Wayland is in minority, for example for Zoom to create proper support.

Is a standard Google Meet meeting in Chrome for Linux on a Wayland desktop not functional?

Usually not, no.

There are two processes that need to be running that somewhat work.

xdg-desktop-portal & xdg-desktop-portal-wlr

Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used.

Might be better under Firefox, but chrome is spotty for me.

Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.

I have run my daily driver Fedora machine with Gnome and no X at all since May 2021, everything has worked really well for me, too.

I haven't disabled Xwayland, but I have configured the apps that by default do not do it (in my case, Emacs and Chrome) to avoid Xwayland and instead to talk directly to Wayland.

(Gnome's interface design decisions are not very good IMO, but that's clearly not Wayland's fault).

At least some of comments on supposed defects in the architecture of Wayland seem to me to be written by long-time X users who simply do not like change. (I used MacOS for 11 years before I switched to Fedora and barely remember X.)

The problem for those that want to continue to use X -- well, Xserver to be specific -- is that nobody wants to maintain it.

> Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.

If I can't run suckless terminal then what's the point of having a computer on my desktop? At that point I might as well kill the GUI altogether!

Does screen share work in firefox or chromium if you disable Xwayland and enable wayland rendering for those apps?

Yes, it works well in Firefox if you have the needed packages installed [0]. I don't use Chromium but apparently that works too.

[0] https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...

Cool. I'm using sway and might need screen sharing in a few weeks. Will check this out.

Xwayland is probably going to be deprecated and removed anyway. It's only included for backward compatibility with "legacy applications". It's like DOS compatibility on Windows.

I guess we should deprecate and remove DOSBox too, right?

DOSBox exists because DOS legacy applications still exist, and will continue to exist for a very long time. The same is true of X legacy applications.

DOSBox is something different. I was referring to the largely incomplete legacy DOS compatibility on Windows NT based systems.

Soon it will get to the point where the UI toolkits that matter will have ported entirely to Wayland and remove their X11 compatibility code. When that happens, all modern apps will be Wayland-native only. That leaves legacy apps and toolkits that haven't gotten with the program. For those, a VM running an old OS with Xorg will suffice. That is the "DOSBox equivalent" here.

Sincerely hope not, I’ll be forced to go back to X11 for jetbrains tools and everything electron based.

(as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly)

EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.

Have you had the chance to report those random crashes as bugs (against Electron or your compositor?) I figure that would be helpful for all.

I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far.

At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release.

The sooner people report those crashes, the better for everyone involved.

It won’t be deprecated, the very reason it exists is that there will always be plenty of software that won’t get ported to Wayland.

With Chromium having decent Wayland support since a while now, I expect Electron apps will catch up eventually. A major DE deprecating Xwayland would give packagers of Electron apps a reason to get around to it.

FWIW about a month ago I was interviewing, and had a few rounds of interviews on Google Meet. I was actually pleased to discover that it "Just Worked" on my Firefox/Wayland/KDE setup. Screen sharing, video backgrounds, the works. Unlike Zoom which insisted I could only use Gnome on Wayland.

I use Google Meet on Firefox on Wayland. Screen sharing works fine (now). It didn't for a while, admittedly, but now it does.

I'm using Google Meet via Firefox on Ubuntu 22.04 and have not had any success with screen or window sharing, so YMMV.

Reply on news.ycombinator.com