The kdbuswreck

I'm not sure what you mean by "stuff" and "this." Are you complaining about caps, kdbus, or kdbus' use of caps?

Caps *are* in the kernel, and with the slavish devotion to supporting things forever, they'll be there for the foreseeable future. The horse is out of the barn. (That being said, the problem with caps is more implementation thn design. If you want some sophisticated policy system, that's never what caps were designed to do.)

Kdbus will definitely be used for a ton of stuff.

> Not being used for much, too, indicates that switching it over to a ticketed service would not be a big job.

I still don't understand what this is supposed to mean. This metadata is attached to kdbus messages because it cannot be provided in an atomic, attestable manner otherwise. A Kerberos-like ticketing system doesn't need any of that. It's the sender that provides the ticket directly to the SS. Even if the kernel were the AS -- which doesn't make sense -- the kernel doesn't need to insert metadata all over the place.

That's the fundamental problem with this ticketing idea: It is neither based on data that the kernel has nor data that is useful to the kernel -- only to the sender, receiver, and authenticator.

I seriously don't understand where this ticketing idea originates or particularly how it relates to the issue at hand. It's like a kid in a candy story that starts yelling about wanting a pony. Umm, I guess it could be nice, but that doesn't help answer the question whether he wants chocolates or gummies.