0

Think of docker containers but for users and their projects. A project begins and the user creates a 'slave-user' to manage and contain the project. This would be similar in a sense to Web Browsers providing multiple profiles.

How I imagine this working

The mechanics of it are simple. A sub-user is just another system user, only this user has a new and novel method to log in.

Their home directory in under a path like '/home/.~<USERNAME>/<SLAVE>'

In the user's master account a link to the slave home directory would be created like '~/<SLAVE>'

Optionally the user would be able to encrypt their own and/or the slave user's home directories.

The slave user would be a member of the group owned by the master user with all files and directories in the slave home will belong in that master user's group, with the relevant group permissions.

Regular applications will be able to be started from the application menu as a slave user by right click and choose the slave user from a sub menu of users headed by sudo (if the master user has that privilege).

Depending upon the slave user's group access, applications which are not normally available to the master user are available in the application menu to be started as the slave user.

Applications started in association with a file from the slave user's home will be started as that slave user. A similar mechanism as from the application menu will be available to choose the master user or sudo to action the file.

In a broader setting federated identity management systems will be able to assign privileges or groups to these users to give them special access.

These accounts would be managed through the master accounts credentials possibly through sudo. In the management and creation of the slave accounts, need mechanisms to:
Lock and Unlock the account
Set/Reset a password to control access
Manage group membership

The sys-admin role user should be able to assign re-assign slave accounts from one user to another and reset password controls. This would of course be the nuclear option.

There may even be template accounts to choose from, like a video editing template, a gaming template or a project template.

The slave accounts have the option of getting a thumbnail tags running applications and the home directory to allow the user to track in which identity they're working.


Some use cases
A photography project. You create a user to manage your photos and this user has access to your photo editing SAAS applications. This could be for a birthday party or a wedding.

A remote working user. Your business allows access via a VPN. The slave user has the permissions to create and destroy the VPN tunnel. This user's browser and relevant applications work over the tunnel, allow the master user to continue to access the regular web and master user processes ideally won't mix with slave user processes... thus the great balancing act of security vs usability continues.

Your boss assigns you a project. The slave user is created as member of a group or groups which can access specific resources apps and/or media. When the project is finished and the user is destroyed the home directory is all swept up in to the main project's archive.

Please let me know your thoughts or if you have any questions.

The basic purpose of this is a separation of roles within one user entity. The most challenging part of this I imagine, is designing the ways that the user entity interacts consistently across KDE.