Multi-user and Multi-tenant support
Created by: vanrein
The current TLS Pool is designed for the following two uses:
- a system-central daemon servicing all locally run server programs
- a system-central daemon servicing a system's primary user
In addition, it should be possible to run the TLS Pool under a personal account with a personalised configuration. Although possible, it's not pretty and ill-advised to do so. For this to work properly, one TLS Pool should prepare to serve multiple users in such a way that they are logically and securely separated, yet managed together.
Management for multiple users in one stroke involves the configuration over SteamWorks. It involves one or more databases, though it may differ between sites which databases are shared and which are not. And finally, a multi-user daemon should support one configuration file that is properly parameterised to support direct paths to standardised places under home directories, and/or to name files by their user, and so on.
Where multiple users come into play, we should also think about aliases / pseudonyms and about groups / roles. The alias / pseudonym angle should be dealt with in the disclose.db and localid.db together with the LID entry API, but group access has not been considered yet. Especially when group access can be as smooth and per-connection regulated as already done for individual identities, it is going to be a highly practical enhancement of the user experience. Maybe groups differ from person identities, maybe not.
A profound area of concern in multi-user support lies in the separation of various users, while retaining co-ordination and some forms of sharing between users. In addition, a point of care is establishing a local user's identity -- where UNIX domain sockets are helpful in passing file descriptors, they are not so useful that the other end's identity can be retrieved as with SysV IPC mechanisms.
The same mechanism as for multi-user support, except perhaps with multiple access sockets, could be used to run the TLS Pool in a host environment, independently of a virtual machine or container / jail. We should consider if this is a viable alternative use case when we consider multi-user support.
On Windows, a multi-user mode is likely to translate to a Windows Service which, like POSIX services, runs only once for the benefit of many users.