Creating a "sub-user" account/environment

Question

I'm working on an old(ish) SLES GNU/Linux machine on which I don't have root, nor do I have a user account of my own: Multiple people use the same user account (often at once).

This is "necessary", in the sense that a bunch of stuff assumes you're using that account and no other one, so I can't just ask for a different account for myself (and it won't matter since that's not a possibility for various reasons). At the same time, I do want to have personalized settings: My own shell rc scripts, VIM settings, git or mercurial settings, scripts I've written which I want in the path etc. And finally - I can't get in the way of other people using that account, i.e. they can't have to put up with me changing their settings, or cluttering everywhere with my own files etc. (and they might want to do the same thing).

My question: Is there a common/established approach to creating what can be referred to as a "sub-user" or "user-within-a-user" account or environment? Perhaps one supported by some kind of tooling/scripting?

Answer 1

Make your $HOME away from home

One-time initialization:

1. install -d /home/shareduser/subusers/einpoklum
2. Copy/link all appropriate configuration files and data directories from /home/shareduser to /home/shareduser/subusers/einpoklum.

Those with quotas on their home directories note that hard linking the files that remain the same, and symbolically linking the directories, is more space efficient than copying.

At every terminal log on:

1. export HOME="$HOME"/subusers/einpoklum
2. Perform similar adjustments to XDG_CONFIG_HOME and XDG_DATA_HOME if appropriate.
3. Perform augmentations to PATH as desired.

Doing this for a graphical log-on is more complex, as many of the desktop processes need to inherit the changed environment variables at startup, the mechanism for which varies according to desktop and operating system, but the same goal applies.

People often forget that HOME is just an environment variable, not magic.

Further reading

• https://unix.stackexchange.com/a/313001/5132

Answer 2

Assuming you don't have simultaneous sessions belonging to two different people. Your best bet use GNU stow to manage this. Stow is one of the most bizarrely useful packages, in the linux ecosystem. What it does is systematically manage groups of symlinks.

For your application you would create a directory that holds the dotfiles for all the people using the account within the user accounts home directory something like ~/.people. Then each person puts their dotfiles in a sub directory under the people directory. So e.g Smitty puts his vimrc or whatever in ~/.people/smitty. Nora puts all her settings files in ~/.people/nora and so forth.

On login each person runs (cd ~/.people && stow $name)

Where $name is the name of the person's ~/.people directory on logout run (cd ~/.people && stow -d $name)

As for automating this their are ways to do it. There are shell scripts that run on login and logout on a per user basis called ~/.login and ~/.logout. Which would be the easiest way to do it. But automating this could lead to chaos. Last time i had something like this set up someone accidentally replaced ~/.ssh/authorized_keys. So my advice would be to avoid that.

If Multiple users at the same time Then there is no sure fire way to do this, without fancy footwork. However programs use the $HOME environment variable to determine where the home directory is for configuration purposes. Your best bet is to use ~/.people/$name as before but instead of using stow have each user run HOME="~/.people/$name" bash -l. This will create a new bash session with the home directory variable set to the per user sub directory and have it execute the same start up scripts as it would if you were logging in normally with the new home directory value. Thus fooling any program executed from the new bash instance which references the value of $HOME for it's config file locations into using the per individual directory instead of the top level home directory. This hack is extremely fragile, and doesn't work with all programs but this is really the best you can do with multiple people on at the same time.

Answer 3

That kind of setup is just screaming for all kinds of "funny happenings". Outdated operating system means all sorts of known vulnerabilities, adding to the entertainment value.

Just ditch that mess, and set up something sane, with one account for each user. There are true and tested ways to set up sharing (groups owning the shared resources, set up ACLs).

In the end, the extra work juggling all this very, very likely isn't worth it.