Quick and Easy User Personas Part 2

Hardware Librem 5
1

So in my previous attempt at making user personas “easy” I ran into a roadblock. Systemd saw that I was bind-mounting a directory in my microSD card over my /home/purism directory and was automatically creating a dependency chain. This meant that if the microSD card were missing, systemd would disable phosh and other dependencies and you’d be left with a blinking text login prompt.

In the interest of making this even easier, I decided to take the approach of hosting each persona in /home directly and make /home/purism a symlink you would change to point to the different personas. Then you could create personas, back them up, and delete them from /home when you don’t want to take them with you.

I wrapped this in a basic yad script and have tested it reasonably well. You can check it out here:

WARNING!! I have tested this script pretty well but because we are dealing with moving home directories around, and because this has a “delete persona” feature, it could remove your personal files (by design!). Be sure to backup your entire /home directory if you choose to try this out.

That repo has a corresponding .desktop file as well. I recommend putting the script in /usr/local/bin and the .desktop file in /usr/local/share/applications. If you store the script in your home directory instead, it will disappear when you switch personas!

Internally we’ve already found a few handy use cases for this, in particular creating a new blank persona that we can use when filming Librem 5 videos, that doesn’t have any of our actual personal contacts or other settings.

Security Limitations

Because all of the personas are owned by the same user, if you were to create, say, a “guest” persona and switch to it, a clever guest would be able to browse the file system and still see your other personas in /home.

A better long-term approach would be to use real, separate users and rely on file system permissions to protect one persona from another. Because phosh on the Librem 5 is tied into UID 1000, changing it would mean modifying phosh’s systemd unit file each time you switch personas, along with adding the plumbing to manage new user accounts. I just haven’t gone to the trouble yet.

Bonus MicroSD progress

Something I noticed after implementing this mode, is that having /home/purism be a symlink is enough to trick systemd so that I was able to move my home directory back to a microSD card and use a bind mount to its corresponding persona directory in /home. When the microSD card is absent, the bind mount fails, but since /home/purism is still symlinked to the (empty) /home/default directory I created for that persona, it fails safely into a fresh desktop.

To move a persona to microSD (which I will probably offer as a feature in a future version of the script), you can follow my steps from my previous persona attempt with bind mounts, only you set up the bind mount from the home directory on your microSD card, to the persona in /home and not the /home/purism symlink.

6 Likes
2

i appreciate you taking the time to attempt this for us beforehand ! :innocent: :smiling_face_with_three_hearts: however, i think i’ll let this one marinate over untill i get my L5 (hopefully later this year. knock on wood !)

3

Can you get away with using chown so that the home directory of the currently selected persona is always UID 1000, while the home directories for any deselected personas are owned by something else? (It is assumed that the permissions disallow any o access, and that group owner equals user owner, so that if you don’t own it then you can’t access it.)

The intention would be not to change the ownership of any files within a home directory - so that changing personas can be fast - but this is never an ideal approach to security. It at least raises the bar on how clever your “guest” needs to be.

Once you move a persona to uSD, file system permissions aren’t really relevant any more - if you actually hand your phone over to a guest to use. Either you or your guest will remove the uSD card. :wink:

4

PS Do you need to do anything with sudoers if you are going to allow guest access? Protecting the personal (profile) is one thing but …

5

That would add at least one extra layer to it, but I do think that ultimately the real solution will be supporting multiple real users. Then we might even be able to switch to a different user without a reboot in between.

To your point about sudoers, that’s another risk with this approach, UID 1000 has sudo root access on the Librem 5 by default. It’s another reason the multi-user approach is ultimately going to be what we should go with as it would be much easier to add new users without sudoers access or even access to certain devices.

2 Likes
6

While we are on the subject, purism has sudo access without specifying a password. I am really not a fan of that. However on other Linux computers (that shall remain nameless) I have also seen that changing that (removing NOPASSWD:, or changing it to PASSWD:) causes some functions to break (because the function assumes that sudo can be issued without eliciting a password prompt?).

Do you know what the current status of the Librem 5 / PureOS is in that regard? Is it safe to remove NOPASSWD: ?

7

As far as I know it should be safe to remove NOPASSWD.

1 Like
8

OK, I’ll be the guinea pig. I’ve changed it to PASSWD: and confirmed that purism is now prompted for a password in order to use sudo - and I’ll leave it for a few weeks to see whether anything breaks.

For anyone following along at home, the offending line is in /etc/sudoers.d/devkit and not in the main file, /etc/sudoers and of course you should always use visudo to edit a sudoers file.

5 Likes