Bug 418834

Summary: Slave-Users
Product: [Applications] systemsettings Reporter: Stephen <stephen.feyrer>
Component: kcm_usersAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: wishlist CC: kde
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Stephen 2020-03-13 21:32:18 UTC 
Please note that prior to posting this I have searched for wishlist items but haven't found anything which obviously relates.

SUMMARY
  Think of docker but for users.  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 WOULD I EXPECT THIS MIGHT WORK

  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.


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.
Comment 1 Stephen 2020-03-13 23:46:14 UTC 
One detail that I forgot to mention is that these accounts would be accessed 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
Comment 2 Christoph Feck 2020-03-14 16:27:53 UTC 
Does the kernel support such sub-users?
Comment 3 Stephen 2020-03-14 20:12:22 UTC 
@Christoph Feck

The way that I envision this, the short answer is yes.  This is at least in the way that the kernel supports any users.

From the operating system perspective these are just regular users.  The difference lies in the way that they are created and used.

These users would be created via a special KDE slave user management widget. 

When you create a regular user, you have many options to specify group membership, home directory and other things too.  The important parts for us are how you authenticate as that user and where their home directory lives.

For the authentication, you could use sudo or su though I suspect PAM is more suited to this sort of authentication.

For the home directory useradd offers the -m option which will create the home directory from the skeleton directory.

This proposal does not change the underlying operating system, it changes the way the desktop environment interacts with the user by offering the user multiple personalities.

To be clear this is a KDE feature, not an operating system feature.


P.s.  I did try to be consistent in my terms.  Here 'sub-user' and 'slave user' are synonymous.  I decided in the end to go with the term 'slave user' as that is more explicit about how this should work.
Comment 4 David Edmundson 2020-03-14 20:23:56 UTC 
It sounds like you're describing Unix groups with extra steps.

We're not doing this.
Comment 5 Stephen 2020-03-14 20:49:30 UTC 
@David Edmundson

Groups with extra steps, yes and no.  In a more abstract sense think of this as breaking down a users activities into silos.  As I said, in the first instance think of this like docker but for users.

Perhaps something similar can already be achieved through Unix groups.  I will read more deeply.

As for you're not doing this, fair comment that's up to you.