It has never been easy to create separate users on Linux, certainly not for tasks where you need to switch between contexts.

Docker was amongst the biggest steps forward on this in a long time.

▲

progval 4 hours ago | parent | next [-]

I meant for CLI tasks. Just "adduser" and "sudo -u <user> bash".

	▲	brookst 12 minutes ago \| parent [-]
		And when you want to share some but not all files with that one user but not other users you created for similar purposes? And when you want the outputs of that user back to your main user? And when you want that user to access some shared credentials for external services, but not all? It’s not the account setup that’s hard, it’s the workflow of spreading a single real-world across multiple accounts.

▲

vladms 3 hours ago | parent | prev | next [-]

I do not know since when (I am using it for couple of years), but in Arch, it is very simple to have two X sessions (by using "log out" > "switch user") for two different accounts, so switching it's just a Control-Alt-F7 away.

Additionally, one can make the main user part of the group of the development user, so that you can read/write easy in the development user account and it is even easier to share stuff.

▲

eru 3 hours ago | parent | next [-]

It doesn't really matter which distribution you use, you can use approximately all the software with any distribution.

They mostly differ a bit in how they are configured and what package manager they use and how they roll out updates. (And in what's installed by default.)

▲

graemep 3 hours ago | parent | prev [-]

Multiple X sessions has been possible for decades. I think its possible with Wayland too.

You can also start applications as another user so you do not even need multiple sessions.

There are quite a lot of privilege escalation attacks so I am not sure this is sufficiently solid.

	▲	wafflemaker 23 minutes ago \| parent \| next [-]
		It's off topic, and it was also possible for decades, but: you can connect two sets of mouse, keyboard and monitor to one PC and have two people using it, each running their own X session. The true multi boxing!
	▲	vladms 2 hours ago \| parent \| prev [-]
		Possible and available without any specific configuration on my side (except creating the user) are different things. I know I managed it many years ago with some effort, but nowadays it was just available. You are correct that it should not be seen as a perfect protection, but considering the effort to set it up I see it as worth it. By seeing in this thread how many people do not use anything similar (ex: containers, separate users, etc), I hope attackers will just be lazy and target those people first, why bother with a local privilege escalation when interesting data is just in the same account?

▲

4 hours ago | parent | prev | next [-]

[deleted]

▲

consp 4 hours ago | parent | prev | next [-]

sudo useradd -m [username] ?

su [username] ?

Or am I understanding your idea about switching context wrong?

▲

indigo945 3 hours ago | parent [-]

This doesn't really when the CLI tool needs to access any data in your /home. There isn't a straightforward way using standard POSIX tools to share a directory with another user. (Of course it's possible, but it's not easy.)

▲

grosswait an hour ago | parent | next [-]

Then you set up a shared directory with common group permissions

▲

tempfile 2 hours ago | parent | prev [-]

If the CLI tool needs to access arbitrary data from your home directory, then it is you. There is no security boundary between you and another user with full access to everything you own.

If you want to share specific directories, you can just put the shared directory in a common location, set it to be owned by some group, and make both users a member of that group. I don't see anything not-straightforward in there?

	▲	delamon an hour ago \| parent [-]
		Or even use acl(5), which is simplier than making arbitrary groups.

▲

j-bos 3 hours ago | parent | prev | next [-]

While I agree, containerization is awesome, on linux, you can just create a devUser and `sudo devUser theThing`

▲

reactordev an hour ago | parent [-]

not the same thing. Containerization prevents devUser from accessing your machine root with its root. By containerizing, if devUser tries to sudo or su and gets a root, it will only be their root and not your root. Read up on cgroups.

▲

progval an hour ago | parent | next [-]

Successful sudo from a cgroup still makes you root on the machine. What you want for this is user namespaces, not (just) cgroups.

	▲	reactordev 43 minutes ago \| parent [-]
		yes, you would setup namespace and unshare it once mounted to isolate the sandbox so root only sees the sandbox / and not your /

▲

grosswait an hour ago | parent | prev [-]

Why would you allow devUser sudo?

	▲	reactordev 40 minutes ago \| parent [-]
		normally you wouldn't but there are some instances where a script or something requires sudo in which case you would need to namespace the cgroup and do a little more work to prevent escaping the sandbox. I can think of a few cases where sudo is required for cgroups/containers from the sandbox side so it can install services and things but ideally you would isolate everything to the devUser UID or GID.

▲

hansmayer an hour ago | parent | prev [-]

[dead]