app_server: Multi-user considerations

[waddlesplash]

This is a meta-ticket intended to collect together whatever is needed for proper multi-user support in/around app_server (this may, ultimately, wind up including most of the GUI by extension.)

Past bugs that need to not regress: #12534

[waddlesplash]

Arguments/support in favor of having per-user app_servers:

from PulkoMandy in #12534:

The argument for using multiple process is mainly about security and making sure that an user can't access another's data. A possible second argument is resilience (if each user gets a separate input_server, an input_server crash could affect only one user and not everyone). Both of these are in the somewhat unlikely case that we even allow multiple users to use a machine at the same time, do we even want to go that way?

from myself:

There need to be multiple app_servers per-user simply due to the 32-bit address space limitation, unless somehow we do not care about that.

The amount of code we would have to add to app_server in order to support that is ultimately, however you look at it, *much* larger and more complicated than simply starting separate app_servers for separate users on just about every level.

from axeld on ​https://review.haiku-os.org/c/haiku/+/4506/:

I wouldn't mind to actually divide the app_server into two parts, but that probably wouldn't really solve the original issue either; it just has other advantages like better implicit security. Dividing into more and more teams has also downsides, though, like a higher memory usage, and more context switches.

[waddlesplash]

Another consideration I don't think has been mentioned yet: "run as." Occasionally there will be reason to run applications "as" another user within the GUI session of the present one (e.g. "run as administrator" for system preferences, for instance.) If app_server is a single server for the system, now it has to keep track of what "session" an application is in, not only what user. But then it also has to keep track of what sessions are allowed to cross-communicate: e.g. if one user has two RemoteDesktop sessions open, these are both the same user and should be allowed to communicate (and even send applications between them); but also the application that is "run as" another user within a different user's session.

With the multiple-app_server model, the application need merely start as whatever user it is, then elevate its privileges and remain connected to the original app_server, which may not even need to know it has changed UIDs.

[X512]

If app_server is a single server for the system, now it has to keep track of what "session" an application is in, not only what user.

This is currently handled by Desktop object. But it currently handles both user session and windows management logic for specific screen. So you can login multiple users in separate Desktops and it will be independent, it is not possible to move windows etc. between Desktop objects.

Maybe it is good to split Desktop object to user session object and screen window management object.

Axeld also proposed implementing multiplexed HWInterface so multiple screens (including remote) will be handled by single Desktop object and it will remain 1-1 relation to user session.