{"action":"opened","issue":{"url":"https://api.github.com/repos/arpa2/tlspool/issues/36","repository_url":"https://api.github.com/repos/arpa2/tlspool","labels_url":"https://api.github.com/repos/arpa2/tlspool/issues/36/labels{/name}","comments_url":"https://api.github.com/repos/arpa2/tlspool/issues/36/comments","events_url":"https://api.github.com/repos/arpa2/tlspool/issues/36/events","html_url":"https://github.com/arpa2/tlspool/issues/36","id":163581837,"number":36,"title":"Multi-user support","user":{"login":"vanrein","id":1358341,"avatar_url":"https://avatars.githubusercontent.com/u/1358341?v=3","gravatar_id":"","url":"https://api.github.com/users/vanrein","html_url":"https://github.com/vanrein","followers_url":"https://api.github.com/users/vanrein/followers","following_url":"https://api.github.com/users/vanrein/following{/other_user}","gists_url":"https://api.github.com/users/vanrein/gists{/gist_id}","starred_url":"https://api.github.com/users/vanrein/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vanrein/subscriptions","organizations_url":"https://api.github.com/users/vanrein/orgs","repos_url":"https://api.github.com/users/vanrein/repos","events_url":"https://api.github.com/users/vanrein/events{/privacy}","received_events_url":"https://api.github.com/users/vanrein/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-07-03T22:00:34Z","updated_at":"2016-07-03T22:00:34Z","closed_at":null,"body":"The current TLS Pool is designed for the following two uses:\r\n  * a system-central daemon servicing all locally run server programs\r\n  * a system-central daemon servicing a system's primary user\r\n\r\nIn addition, it should be possible to run the TLS Pool under a personal account with a personal configuration file.  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.\r\n\r\nManagement 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.\r\n\r\nWhere 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 a 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.\r\n\r\nA 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.\r\n\r\nOn 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."}}
{"actor":{"display_login":"vanrein"}}