taway098123

There's no code I can show you that would be any more convincing than just looking at the code to the X server and then looking at the code to any wayland implementation. There's not anything particularly special about these projects.

I was familiar with that documentation around 10 years ago, please stop making these assumptions and please stop dismissing what I have to say. The documentation is irrelevant, I'm talking about the server source code. There is one real plugin implementation there that uses SELinux. That's it. There is currently no other real way to use XACE, it's otherwise totally useless to end users.

Yes people could develop new plugins that integrate with some other security mechanism, but they haven't, in part because the hooks are so out of date, and in part because, you know, that requires building another security mechanism. The access hooks are not a security mechanism, they allow you to integrate with some external MAC.

As someone who has done both, I respectfully disagree.

It's not wrong, it's not FUD, and that doesn't change anything. The only working plugin is the SELinux one. If you can't use that, you have to rebuild an entire new security architecture... which is what they had to do in Wayland anyway. XACE isn't really built for anything besides MAC either, so it's inadequate for doing anything that isn't an LSM. It also has a problem where new hooks need to be added for every new X extension, and that didn't happen so now it's outdated. In Wayland that entire concept was replaced with a single API function to do generic traffic filtering.

It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...

There isn't really much difference. It's about the same amount of work either way to ship an extension.

In Wayland, you make the extension, then you patch every compositor, every toolkit and every application.

In X11, you make the extension, then you patch the X server, Xlib, XCB, every window manager, every toolkit, and every application.

XACE doesn't solve it. As mentioned elsewhere, that's dependent on SELinux. The idea with Wayland is to make things more secure everywhere, and not just on systems that have a particular LSM.

I completely disagree with everything in your comment. Wayland is an attempt by some developers to fix some longstanding issues with X11. They know what the new issues are and there is active work being done in preserve back compatibility and preventing things from breaking, e.g. XWayland. I've been using it for a few years, with no issues. I think it was bad up until around 2017-2018, that's when the major implementations started stabilizing and when consensus really started happening.

Dbus won't allow it because you have to switch to that user before it lets you connect. You would have to have whatever is doing the access running as root and then change its user. There's not really any magic here, it's just a socket with access controls on it, the same thing you would be building anyway.

I'm sorry about the throwaway, it's a long story.

You're crossing a security boundary trying to access other users' GUI programs. The session bus is for programs that are private to the user's session. Accessing that is mostly equivalent to logging in as that user, you're not supposed to take control of all their programs as another user.

I don't really understand your solution, the problem doesn't go away when you use a Unix socket. You're still crossing a security boundary and now you have to build in those access controls into your program. If you don't really care about the security aspect it would be just as easy to tell the user to grant you access to the dbus socket for their session bus, or run another dbus instance under a different user and control access to that socket. You can publish the same interface on multiple buses at once, and build in your own access controls too.

Yes it can, why wouldn't it? You can make a program that connects to more than one bus. Though that would probably be crossing a security boundary. The simple way to make multi-user services is to just deploy them on the system bus and be done with it.

You just kill the process, which causes the file descriptor to close. Cancelling the inhibitor lock by other means wouldn't do much, there's no way to get out of that situation without forcibly shutting the process down or disrupting its state.

Dbus is mostly just a message queue for Unix sockets. Think Kafka or SQS but only for local services.

>a protocol prescribes exactly the intersection of all implementations.

That's a better way to put it and that's more what I was getting at.

I hope someone comes along to review those, but I don't see there being much interest in it.

Everything you're saying is... mostly what's been happening? It's not impossible to have consensus. You're missing my point which is that people were trying various solutions since 2008, and there just wasn't any consensus on this particular feature until a few years ago. There's no reason to put it in a spec if there's no consensus. It turned out that the consensus was to not put this in a Wayland protocol, and to do it somewhere else. So it would have probably been a mistake if someone tried to force this through before then.

If you ask me, people only notice the ones where it takes a while to reach agreement. Just look at the PR we're commenting on, it took nvidia several years to come around and implement dma-bufs. Sucks but it happens. No one ever seems to pay attention to all the other areas over the years where there was consensus.

There's plenty of ways to securely multiplex Ethernet devices. You don't give your web server read access to all TCP ports being used by other services for example. You only let it open the HTTP ports. There are of course ways for debuggers to escape this and intercept all TCP packets sent by the kernel, but those require elevated privileges.

I mean, no, it's not the fault of Weston developers that other implementors decided do their own thing. I asked this before but what could they have done? Putting tons and tons of things in the spec wouldn't really have fixed the real problem, which is that the way they wanted things didn't exist at that time, and the only way forward for them was to write their own implementation. The spec is only meaningful if you can get other people to promise to implement it in the way it's supposed to be implemented. It's true that Wayland is just a protocol but that protocol is also defined significantly by its implementations.

>I can't think of anything that more succinctly illustrates what's wrong with how Wayland has been developed over the last 13 years.

I don't understand why and I wish you wouldn't do this, this is leaning into flame war territory. If you can explain your point to me in a way I understand, then I'm ready to listen.

The usual place those permission dialogs have gone is the flatpak portal, which is separate from Wayland. Someone would have to implement it there.

Any implementor always has permission to do their own thing, that's the point of making a second implementation. Putting something in a spec somewhere doesn't make it mandatory or guarantee it will be implemented. They could have put the weston screenshoot protocol that was created in 2008 in the spec, but they didn't do it, probably because the other implementors said it wasn't good enough and they didn't want to implement it. So what more could they have done? The mailing lists around that time had a lot of suggestions that went nowhere. Trying to put pressure on open source developers to implement something they don't want to do doesn't work, unless you are their boss paying them a salary.

I'm being serious here, I legitimately don't understand what you're pointing out. Yeah I too wish everything I was planning on 13 years ago turned out perfectly, things don't work like that though. And if you ask me, the thing that's most comparable to IE5 is the Xorg server.

I don't see how I am, and I don't understand your point. The reference implementation had screenshots. The other implementors decided not to copy that and did their own thing. What more could the Weston developers have done? They can't force the other implementations to write code that they weren't interested in writing.

You misunderstand, it was only Weston that was started in 2008, and it had screenshots back then. I'm talking about those other implementations, they didn't really stabilize and start aiming to have feature parity until a few years ago, and they decided not to copy Weston's screenshooting mechanism.

Most developer activity related to Linux graphics is in dri-devel, it's been like this for quite a while. The X development channels have been mostly dead outside of discussion of XWayland. I doubt you'll see anyone starting any major new features in X.

These aren't excuses, there are no other parties at play here. Weston was the first implementation. GNOME and KDE were the next implementations. They could have chosen to copy Weston's implementation, thus making those parts "standard" but they didn't. That's the way it played out. The way you're talking about it makes it sound like there was some outside force designing Wayland and convincing the other designers to exclude screen sharing, when it wasn't like that at all. You also seem to be suggesting that they could have designed everything in hindsight perfectly before the implementations even existed, I hope I don't need to point out why it doesn't work like that.

You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.

That's one way to do it, it's probably not the best way but it would work if you were planning to sidestep Wayland security completely. You could make it user controllable with dbus and then make a GUI to talk to it.

That seems like the reverse of the way it's always been on Linux, where there are only developers and no users...

If you have root access to your own system, or read access to /dev/input, then it's trivial to deploy a keylogger. No need for Wayland to get involved there. You can't log keys through the Wayland socket because that socket is intended to be accessible to sandboxed programs.

All of those questions are really irrelevant. The point with Wayland is to make something that's more secure than the systems it aims to replace, not to make exactly the same thing. If you want to help, maybe show a way this can be done without poking a huge security hole?

Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.

Screen sharing and screenshots weren't an afterthought. Weston had support for those for a long time, but gnome and kde decided to do something different, probably because they saw pipewire was maturing.

Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want.

The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.

You misunderstand. In both situations, you're making a new protocol. The only difference is you'd be making your own thing instead of adding new packet types to Wayland. And why add new packet types to Wayland if the thing you're trying to do can be done outside the Wayland socket? Best example is Pipewire and screensharing. People ask for screensharing in Wayland but it makes a lot more sense to have it in Pipewire because it can handle all the other tasks related to video streaming like format negotiation and compression. It works headless and independent of any compositor, the fact that it can also be used to do screensharing is a benefit of its design.

Not sure why you'd laugh or cry. Dbus is just an example. You can use another mechanism to build another daemon, it doesn't have to be built on anything in particular. I'm just saying, if you expect that Wayland is going to solve every problem you had with your desktop, you're setting yourself up to be disappointed. It solves a few specific problems. You can solve the other problems in ways that reduce fragmentation, but you'll have to look in other places.