Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think most people with SOs or families see the benefit of having each user of a shared computer having their own user account.


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.

fortunately haiku does have multi-user support in the kernel, it's just not implemented in the GUI yet.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: