https://bugs.kde.org/show_bug.cgi?id=418834

            Bug ID: 418834
           Summary: Slave-Users
           Product: kuser
           Version: unspecified
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: gyu...@freemail.hu
          Reporter: stephen.fey...@btinternet.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to