Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 28 |
Nodes: | 6 (0 / 6) |
Uptime: | 51:38:15 |
Calls: | 422 |
Files: | 1,025 |
Messages: | 90,554 |
Is there some way to setup a machine such that one user can login into it
and see a Debian stable system, while another user can log into it (in another vty) and get, say, a Debian sid system?
I don't really want different VMs. I'm thinking more of a setup based
on containers or even just chroot.
How would you run both the Debian Stable and Debian Sid kernels at the same time without virtualization?
Is there some way to setup a machine such that one user can login into itWhy don't you want to go down the VMs road?
and see a Debian stable system, while another user can log into it (in
another vty) and get, say, a Debian sid system?
I don't really want different VMs.
Just trying to understand your reasoning! :)
Is there some way to setup a machine such that one user can login into it >> and see a Debian stable system, while another user can log into it (inWhy don't you want to go down the VMs road?
another vty) and get, say, a Debian sid system?
I don't really want different VMs.
Just trying to understand your reasoning! :)
Not necessarily opposed, but I'd like to keep the feeling that it's "one system" as much as possible, e.g. in terms of filesystems mounted, or
when connecting a USB device, etc...
The main issue is that some users want a system that doesn't change very often, while others want the latest updates of their tools.
So ideally, users could choose which they get just like they can choose
from the GDM login which DE they get.
Stefan
Is there some way to setup a machine such that one user can login into it
and see a Debian stable system, while another user can log into it (in another vty) and get, say, a Debian sid system?
The first way that I can think of is extremely hack-ish.
Install stable normally, then install sid in a chroot using debootstrap.
Add the desired user accounts to the sid system.
Next, write a little C program that executes a command like
chroot /sid /bin/su - getenv("LOGNAME")
Compile it, and then install it somewhere with root ownership and the
setuid bit enabled. **THIS WILL RENDER YOUR SYSTEM COMPLETELY INSECURE**.
So don't put anything important on either part of this system.
That's the kind of solution I was hoping someone has developed enough toSee RootDirectory in systemd.exec(5). It can be set for specific users through user@<UID>.service.d drop-ins. Perhaps it would be necessary to create a .desktop file in /usr/share/xsessions/, I have no idea which way
iron out those major security issues (e.g. letting GDM do the chroot
before it changes its UID to that of the user).
GDM spawns session executable (e.g. using systemd-run equivalent or
not). RootDirectory affects processes started by pam_systemd and other parts of systemd user session.