Modern multi-user paradigms also have very weird ideas of what’s shared. Like, installing or updating software is the same permission tier as accessing another user’s documents, wtf?

_Technically_ it doesn't have to be.

Super user is super user. It can always access anyone's files. Allowing unrestricted access to super user essentially destroys any sense of security.

You can very much allow only access to certain commands under super user, e.g. only allow users to run pacman. Of course now you are trusting that said commands won't leak the permissions.

I agree that it's a mess.

My personal and biggest issue is not even across user boundaries, but inside a single user.

What do you mean my Firefox client can read my .ssh files???

I almost linked that in my ggp comment, but really I’m making the opposite argument as the comic.

Either way you slice it, though, it’s clearly a huge disconnect between what is important to the human using a system vs what is important to the system itself, and the relative lengths gone to to protect those two sets of things.

it does not make much sense as you typically protect important online activity with 2FA

> Like, installing or updating software is the same permission tier as accessing another user’s documents, wtf?

To some extent, yes. If I can install software of my own choosing on basically any normal desktop OS that will appear to other users of the system as "LibreOffice", "Firefox", etc. then I more or less have access to all their data.

MacOS is starting to sandbox applications but not by a lot, and of course Windows Store sandboxed apps are more or less dead in the water.

Do not mix Windows Store (UWP) sandboxes, with Windows sandbox, which not only is pretty much alive, is making its way across Windows 11 updates since last year.

Check "Windows 11 Security", "App Isolation", "Sandbox", "Standard User", "Pluton".

https://github.com/dwizzzle/Presentations/blob/master/David%...

Don't mind me, just updating the software you use to access your documents, nothing to see here, move along.

To me, a "modern multi-user paradigm" is Nix with Home Manager. Where most of my software is installed in my user's environment and not on the system level. Thus, if there were another user on the same machine, we could each manage our own software and updates without affecting the other.

> Nowadays computers are almost never shared.

I find it ironic that Google TV still does not have this feature, it is the one "computer" that people probably still share regularly.

Sure you can login to multiple accounts and have different "profiles", but that just changes home screen recommendations, all the apps and their sessions are shared. So since I share it with a few roommates, we're constantly having to logout and in to our accounts in different apps to access our watch histories, our plex servers, etc.

On the other hand, my android phone does multiple accounts perfectly, why can't it work the same way on the TV?

Just buy another Google TV and hook them up to a KVM switch.

OS security always requires a concept of a user, unless you want to run all processes under the same identity.

You could do with some other concept than users. E.g. namespaces or capabilities.

It is another way to call a "user", hence why I used the word indentity instead.

No its not. There's all sorts of stuff you can do with capabilities that are really awkward to even think about with users. Like, when a database starts, you can hand it the capabilities it needs to access a specific directory, listen on a specific port and append (but not read) a specific log file.

User based security is usually done by the folder being owned by the database, or an ACL or something. But with capabilities, you don't need to make a database user or set any flags on the folder, or make sure the database's configuration matches the filesystem permissions. The capability is basically a pre baked file handle that can be used directly. And capabilities can do lots more stuff! They can be more fine grained - eg, "Whatsapp can only access these specific photos in my camera roll". And a program can pass a subset of its capabilities to a child process.

Capabilites have ownership, ownership requires belonging to something, all the way up to booting the OS.

Capabilities can just be variables. Variables all belong to something, all the way up to the OS. Would you say variables are a type of user permission? Obviously not. Variables are more versatile than that. So are capabilities.

This is what uid and gid are used for in Linux respectively. There is only a concept of "user" and "group" when you add a Unix-like operating system in top such as GNU or Alpine.

But if you're sandboxing and running all applications in a separate space, is it really correct to refer to it as "users" anymore?

3rd party apps are written (controlled) by other people, and you are effectively granting that 3rd party permission to run their code on your device, so the user concept isn’t that far off the mark. Since ~nobody reads the source code of 3rd party apps, security vetting is usually a matter of deciding to trust the app’s author, same as how you would trust anyone else that you give a user account to.

You grant them capabilities, a handle which permits access to a particular directory, one which allows network access (or possibly even further limited than that) etc.

No user, just a series of object handles which permit them to perform the task and nothing more.

Sure, but capabilities and handles are technical terms of art below the level at which regular users need to understand. The idea that an app is another person using your computer is not a terrible abstraction in terms of helping people make sense of what's happening.

Maybe. But they're a bad mental model for software developers because user based security is way more limited than what you can do with capabilities.

And they're confusing for users, too. Signal isn't another "user" on my phone. Its still me. I just decide what capabilities I grant it on the day. "Yes, you can use location tracking for now - but only until later in the day."

Capabilites are just another way of doing role management in processes, and require identities for administration anyway.

It is yet another way of managing processes identitities.

A capability is not an identity. And the difference matters a great deal in how you build software that takes advantage of capability based security models.

Identity is reflected by who owns the capability.

Capabilities are often transient. Or in a capability based OS, capabilities are given to a process when it launches and the capabilities naturally go away when the program closes. "Who owns the capability" is the wrong way to think about it. But I'll lose this argument.

Because I suspect if you really want to, you really can think about all "permission systems" as identity systems, and shoehorn in users or something. This cognitive distortion is totally possible. My claim is that its a bad mental model. Its like if you mentally translate all programming ideas into assembler, or java or something, it would make it hard to properly understand and appreciate a lot of higher level programming ideas. Haskell's beauty doesn't make any sense if you mentally translate everything into java. There are programs you just can't write with this mindset, and you would be a terrible haskell programmer.

Its the same with capabilities. They're not user accounts. They're not identities. They can be transient or persisted. Fine grained or coarse grained. A capability can be a function argument - arguably the C FILE struct is a capability object. Or they can be a permission box. Its just, a bigger idea than identity.

You're so obviously correct in this. TBH I think the only reason the term "users" come up when it comes to isolating programmes from one another is because that was the only hammer Unix had, so it was coopted. The original point stands, the actual multi-user aspect is completely secondary and unnecessary to 90% of people. I'm the only person who uses my computer, but still I want to be able to isolate application 1 from application 2.

That sounds like just brutally quartering users into their granular permissions. ;-)

Maybe? I guess the difference is that with a capability object model (or similar arrangement) the _only_ way the application has to interact with the outside world is via those objects/handles it's been granted. There's no risk of escape because they only have access to the handles the process has been provided.

It's almost the opposite of a permission model in some ways, permission models restrict access to a global array of functionality where capability models allow access only to what's been provided.

Sorry. I was joking. It feels like you are giving applications small fragments of the user.

Sorry, I appreciate the joke (really :) ) but I also worry that people keep trying to add the concept of "users" or an existing role or permissions model into capability-based systems when they're unnecessary.

You could maybe model or emulate a user in a capability system by providing the login's session manager an object with read/write access to the configured "user" directory, read and execute access to an applications collection, and full access to the root window. From there, when the user starts a new application it's given an object with access to a window created for it (by calling "createWindow" on the root window object, so it can't even do something like enumerate other windows or whatever), and whichever other requirements were configured as part of its install.

It's capabilities all the way down with no "user" involved.

This is a very Android centric viewpoint ;)

Unpacking that witty but cryptic comment:

Yes, you can have privilege-based security without user accounts, if you accept that you do not have control over your own hardware because only the OS vendor has administrative rights.

In other words: yes, you can have no-sign-in and no user accounts, but it's still there and you don't have admin access to your own computer.

Stepping back a level:

Smartphone OSes do not show accounts and permissions, but they are still there, just concealed. Same as they still have complex filesystems, but they are hidden.

Stepping back another level:

This is a bad way to design OSes: when you need to hide away major parts of the functionality, then you shouldn't have that functionality. It should not be in your design in the first place.

> Yes, you can have privilege-based security without user accounts, if you accept that you do not have control over your own hardware because only the OS vendor has administrative rights.

Or maybe just that the really in-depth administration and modification of your operating system happens prior to the OS running on your device, when it's being built — as a sort of configuration or specification step that happens prior to even installing the operating system or booting up your computer in the the first place, in a continuous integration system in the cloud perhaps, or on another existing computer? That's kind of how Fedora Silverblue works — almost everything you do is completely in unprivileged space, in a container or with a flatpak sandbox, or through policykit; you basically never use the root account at all, because you can't really do a whole lot of really in-depth customization of your OS internals on the operating system image that's actually installed and running on your system. Instead, you specify the modifications you want to make to an upstream image using something like BlueBuild[1] and then those modifications are automated and happen prior to anything ever hitting your computer in an automated ci/cd system (which could theoretically be self-hosted).

Like, I think there is a way to adapt the security and reliability benefits of the way e.g. macOS works that doesn't take control away from the user, just moves it somewhere else. And I think it's much safer for all of the really deep modification of your system, all of the system administration you do as the root user, to be essentially air gapped from the computer that you're actually running various applications and installing and building things and curling to bash on, on a system that's ostensibly clean.

[1]: https://blue-build.org/

Even iOS has different users for all those processes running on the device. :)

Not to any reasonable capacity

Today, the same OS core is used in phones, laptops, desktops and servers. Explicitly making it single-user means giving up on servers and parts of the market for the former three.

You could make the case for removing the concept of users from the kernel and forcing the OS to write some security plugin. The OS could then have a tailored security mechanism for every usecase, but they'd probably end up including users anyway (for the people who do want them).

One such case is company-issued phones. They require the company-provided apps to be isolated from any user-specific configuration, creating an effective multi-user system where user apps (such as Apple Music) run with different privileges (and network access) than, say, Teams or Outlook.

I think this is a good idea anyway. I love how if I install some dodgy app on my phone, it can't access the private, stored data of other apps. It can't steal my google or facebook credentials. And it can't cryptolocker my filesystem.

My desktop computers are designed with this old "user security" model that I don't use at all - since I'm the only user anyway. User security protects ... uh, the operating system I suppose, which I could reinstall in 20 minutes anyway. But we're missing a much more important security boundary - which is between one bad program and all my other stuff. Every program you run today on desktop is inexplicably executed with full permission over all of your private files, and, worse, it has full network access. Its an insanely terrible design.

We /could/ retrofit the user security model to help us isolate applications. But personally I think it would be easier to just design and implement something good from scratch.

(For the security people in the room, the threat model is a bad program, or single bad npm package gets pulled into a program you run. How do we limit the blast radius?)

You might be interested in Qubes OS, which runs every application in a virtual machine.

https://en.wikipedia.org/wiki/Qubes_OS

Every app on your phone runs as a different user

Having grown up with RISC OS, I never considered lack of multi user an omission. But the lack of process isolation (or simply: lack of processes) was a real head-ache.

No memory protection or hardware access, rudimentary virtual memory "page mapping". Any tardy calls to Wimp_Poll() freezing the entire GUI. "Cooperative multitasking" also means it's still impossible to do something useful with more than 1 Raspberry Pi core.

So: lacking in foundations, yes. But multi user, not so much.

Fair. On reflection I agree with all the people that have pointed out that multiuser isn't that important. It was just, historically, the feature that made operating systems become serious about security, which is now essential for other reasons.

After the PC revolution, "User" became synonymous with roles. root, bin, mail, daemon, sshd, www-data are probably some of the users on your system.

Single-user means I have to trust everything I run.

I mean, some of us here actually remember MS-DOS. It's not a huge secret to us.

> Nowadays computers are almost never shared.

That doesn't seem very accurate, unless you're meaning strictly personal computers?

Multi user is getting replaced by virtualization / containerization. The layers are simply getting shuffled

I think pervasive process/app sandboxing – or at the very least proactively and aggressing limiting process capabilites a la OpenBSD pledge and unveil – is a key development as well that's over the horizon as well.

(What's old is new again with virtualization: IBM took that approach to make time-sharing happen with CP/CMS on System/360 – then VM/370, then z/VM...)

> I believe multi-user systems are actually an ancient, outdated rather than a "modern" concept.

I thought that in the 80s, and even had the same experience with sharing the family PC. Then networking (and the internet) happened, and suddenly multiuser became quite useful again - even at home.

> Modern security can be done better without an OS-level concept of a user.

Perhaps, but I have yet to see a userless model that doesn't have issues on around administrative access control. Even dumb terminals had issues with this where students would change settings and then set the admin password on the terminal... As long as people use computers, users will be users...

multi user support has other purposes. it means you can turn the OS into a server OS which can be shared across numerous accounts. lacking that capability means you dissociate a desktop OS from a server OS for no good reason.

I share my desktop PC with my kids and wife (although, TBH, I use the PC 90% of the time and the rest of the family uses the remaining 10%). Although we use the PC one at a time, being able to each have his own environment does help. So multiuser is cool for me.