Future plan for multi-user: (Multiple sys-gui's or multiple users in one sys-gui for sys-gui muti-user?)

sys-gui is supposedly part of the long term plan to go multi-user. Is the idea that each user would have their own sys-gui vm to log into? Like sys-gui-bob, and sys-gui-jim, and sys-gui-peter?

Or is the idea that admin would be dom0 and sys-gui could be all non-admin users, with multiple users in /etc/passwd of sys-gui?

1 Like

I’ve played around briefly with multiple sys-gui-vnc qubes for a machine that is stationary and remotely accessible, and matches your first paragraph. But this is a different use case than local, physical multi-user.

The qube structure is as follows:

  • gui-user1 [configured “like” a sys-gui-vnc]
    • user1-work qube
    • user1-personal qube
  • gui-user2 [configured “like” a sys-gui-vnc]
    • user2-work qube
    • user2-personal qube

It was necessary to make sure the guivm preference for the user[X]-qubes were set appropriately. Then run qvm-sync-appmenus within gui-userX to get them to show up in the menu.

I left default_guivm set to dom0. As long as a user can remotely access gui-userX over VNC, that allows them to interact with userX-qubes, though in a limited fashion. Changing of netvm or template cannot be done unless the respective qubes have their guivm also set appropriately.

The only difficulties I’ve had were in the secure copy + paste mechanism, and needing to set a login password at boot via rc.local.

1 Like

That’s neat! Any idea if that’s what was intended when they talk about future multi-user in qubes?

I’m speculating that future multi-user is intended to work something like:

  1. Boot computer

  2. At dom0 login screen, go to the upper right and select “sys-gui-bob” (which is configured “like” sys-gui)

  3. type in the username “bob” and bobs password
    {you are now logged in as bob}

  4. log out

  5. from the upper right and select “sys-gui-peter” (which is configured “like” sys-gui)

  6. type in username “peter” and peters password
    {you are now logged in as peter}

1 Like

No idea, but these words from the Qubes team are the most recent updates:

1 Like

I found a reference to it: “Also, in the multi-user case, each user will presumably have their own GUI domain, so the system needs to know which one to launch.”

from:

1 Like

Maybe you can create a new dom0 user, and configure that it requires escalated privilege for the new user to run any command/software in dom0, including starting new qubes, etc. He will only be able to use those auto-started qubes. You can also choose to do similar things on those sys- qubes.

1 Like

This is exactly what I would like for my mom as a user!

Since this still doesn’t exist (multi-user in Qubes with a local admin account that is the only one with SuDo and ROOT access), has there been a guide for people to implement this. I assume it will be technical and a lot of CLI commands, because Qubes has yet to enable this so it seems it would be doing a workaround to mimic multi-user as the only true way to get it would be to alter the OS itself

I once tried the “user Group” method and quickly found out that the Templates will not load without a user being placed within the “wheel” group, of which of course has SuDo enabled

Seriously?
As you say, this feature doesnt yet exist and Qubes is a single user
system.
If you are genuinely under attack as you say, then the last thing you
should do is fiddle with new, untested features. Use Qubes as it is
built and intended.
If you want features that do not form part of Qubes, look for some
alternative that does provide the features you want, packaged and tested.
I cant stress this enough. The risks attaching to bolting on untested
and preliminary code are likely to negate the whole point in using
Qubes.

There are some things that you can do to make things easier for your
mother. (I’m making assumptions here based on hints you’ve dropped -
apologies to your ma if they are misplaced.)
Create custom menus that include the programs she will want to use,
linked to disposables where necessary.
Dont include any menu items for terminals, etc.
Create qubes to hold data, but with mime entries to open files in
disposables.
Create helper scripts to make some workflow easier.
Separate security domains and allocate them to different desktops
(Activities in KDE)
Make Qubes as similar to whatever your mother is used to as you can:
hide the complexity as much as you can.

1 Like

I don’t understand, I thought technically speaking further separation by making less privileged user accounts would make the system safer … ? This would for whatever reason by the current coded architecture risk possibility making new vulnerabilities, is that what you are conveying here?

Just FYI, I have made 2 users already on both her laptop and mine. They currently have the same privileges though, as I cannot figure out how to strip one of SuDo without losing access to the menu bar and qube VM launcher menu. I stopped there on this specific tweak after getting stuck.

Yes, I am doing this
:slight_smile:
Thanks for reassuring that I am doing that right at least to set my mom up properly.

I don’t know how to do Qube script stuff, so this will not happen any time soon sadly

I think I understand what you mean here, and I think I do have a plan for this. However, if you could be a bit more clear as to what this entails then I will know if I am on the right track or not. Thank you btw

If she was a different kind of mom and user I would, but I showed her the QubesOS GUI already and explained the concepts and how to get around on the default desktop. She is up for the task of learning a new desktop UI, so thankfully I don’t have to fiddle with too much. I did of course customize it, asked her where she wanted the menu bar to be and what colors etc
(I am upset she likes Light Theme lol)
In other words I don’t need to switch to KDE for her, which to my understanding is a good thing as I read in passing on various threads here that KDE may open up vulnerabilities too but I am unclear still on all that.

Hey, while I am well past the installation phase; for future reference…

Blockquote
" Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks. For example, you can keep templates on one disk and app qubes on another, without messy symlinks.
These steps assume you have already created a separate volume group and thin pool (not thin volume) for your HDD. See also this example if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the -T option on lvcreate to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section."

source:

Would doing that :point_up_2:t3: add or subtract to any security benefit(s)?