I don't know the details about Haiku, but at the end of its life, BeOS had some kind of multiuser support, in that the OS was aware of UNIX-like permissions in the filesystem (and for processes I think). But there was no GUI for logging in, so you were always root.
It was meant for single-user workstations. Not having multiple users was not really a problem, except that it made (makes) some people look down their noses. In this day and age, the main security issue on my workstation is that I all applications - including the browser that downloads a bunch of untrusted code and runs it willy-nilly - run as the same user that owns all my important files. I'm a lot more concerned about what's in my home directory than anything under /usr!
So if and when Haiku adds security measures to isolate applications from each other, I would prefer they looked at some kind of sandboxing to isolate every app from each other, rather than just copying the basic UNIX model, which does basically nothing for the problems people actually have.
(OK, if you need to share a computer which another person you can't have separate settings and browser histories etc., but.. I don't know if that's really such a big deal that it needs to be tackled before the other one)
1) We used to share desktops with family before multi-user was a thing desktops did.
2) With smartphones and tablets and the like providing most of the functionality that people once shared a desktop for (web browsing really), there seems little reason to share one anymore.
3) I think having multiple user profiles one could switch between would cover almost any remaining use cases without the complication of multi-user in the kernel itself.
> for a usable multi-user system it is necessary to be able to protect files from other users. a simple profile is not enough.
That is what encryption is for. The big difference of course being that encryption is not one privilege escalation or boot disk away from being completely useless.
ok, so if we don't have multi-user support in the kernel, but instead implement it only as a layer in the GUI, each user gets a partition or disk image that is encrypted as their home directory that is mounted on login. the file/partition is protected against deletion.
i suppose that could work, but i see a few downsides to this approach:
all processes run in the same space. if i want to run a process in the background my home directory has to be remain mounted, and thus potentially be exposed to the next user. or i'd have to create a second partition for this special process which only an experienced power user would do.
so while i think this approach is possible, it doesn't look like it would make anything easier. on the contrary. the emergence of hostile apps on android demonstrates that privilege separation of processes is becoming more and more important.
the current multi-user approach is not good enough even for that. but instead of simplifying multi-user support to a single user, we actually need to make it more complex to properly handle multi-user-per-process separation.
Privilege separation for applications is not the same as having separate user accounts.
> but instead of simplifying multi-user support to a single user, we actually need to make it more complex to properly handle multi-user-per-process separation.
I disagree. This is such a small and vanishing use case that adding complexity for it is exactly what you shouldn't do.
Privilege separation for applications is not the same as having separate user accounts.
true, and yes, maybe the whole system needs to be redesigned for that. but nevertheless, this needs to happen in the kernel. and once we have proper process separation, adding multi-user support on top of that seems almost trivial.
Arguably you are one privilege escalation or boot disk away from being compromised to the point that the other user can acquire your passphrase or key from memory. If merely a passphrase it could even be gathered by a device between the keyboard and computer or plugged into a usb port.
Security vs someone who has physical access to your machine while you aren't there will probably remain crappy.
