You seem to prefer using the terminal to handle permissions and think that this is a very simple way of doing things. Compared to doing these things graphically, there has been a consensus on which is preferred within the context of a desktop operating system, and it’s overwhelmingly in the graphical side’s favor.
I see this way your sentence.
However I would mention that most people - or I should say generic user - who use their computer, does not care about permissions as they do not know they should take care of it… This way it does not matter they do it on gui or not.
I admit most people do not want to learn commands – as practically do not want to learn itself - as it turns out often when I try to explain the stuff to understand why those happened on their machine and what they should have done instead.
They just want that to work as expected - as it happened in the past when they used a TV or a car. They forget that they had to learn how to use reliable that TV or that car.
For the car they had to learn rules as well, not just how to operate (drive physically) the machine, but how to drive safely and legally too on the roads.
I mean that way : they did not want to know exactly how these machines worked inside until they did what they expected from them. They would like to use a computer this way.
They can do it - until first surprise : the conclusion of their act and missing knowledge. Failure or damage or just an error occurs.
I know - on this forum most people are the opposite : they know about computers and experienced users mostly, so this way have opinion what they need on their machine how they would configure etc. however still they want to use known apps from another environments not just rebirth of old BeOS programs,
I would say that because they want to spare such learning of new things, they just satisfied those apps and would not loose their proficiency in them.
Of course sometimes an app can be a one and only solution as does not exist similar one on another platform. For example as it is proprietary and there’s no intention to make available on another platform (e.g. Adobe softwares on Linux) - so in that case they are right.
Anyway
I had not stated the posix way of permission is better – I just say it is better for ME due to my experiencies on both environments.
I think that first step should be running user applications with non-root user. Running everything with root is dangerous.
6 Likes
something needs to be done to protect specific files and directory’s. Is multiuser the right model ? Or something like a windows security model better ?
What I have always liked about linux is being able to use multiple partitions, I have always considered it very convenient to have home in a separate partition, and a system partition, perhaps like android, native, armored in read-only, available to write only for updates, and therefore, having another partition available in writing and reading for the data managed by applications and the system.
it happened to me often on linux to keep the home partition intact and rip the entire rest of the system, sometimes totally changing distro, this thing I found very convenient …
this is just an example, I just wanted to highlight what I think is useful from other systems
A protected system partition for core system files seems like a solid idea.
1 Like
It is just the cheapest workaround they were able to came up in their constraint system. It is a hack, not a sane, planned solution.
1 Like
It’s not even that. The reason UNIX has mount points and multiple partitions is because it wouldn’t fit on a single hard disk (10MB or so) when it was being developped. Sothe core of the system was split on two disks (/ and /usr) and the home directories to a third one. They could have split it in a different way, but this is what they came up with because it helped with their backup strategy or something like that.
Now our hard disks are 100000 times larger but we still live with the legacy of that.
4 Likes
The two are somewhat unrelated, but the influence of the way it was done in unix is very strong, I see.
Multiuser is a way to have multiple users using the same computer and having their own directory for their files, and probably their own settings for system and apps. This can be done independently of security and isolation (example: Windows 98).
We already do some security and isolation with the read-only packagefs. We could do more (disk encryption, …). We currently don’t really do multiuser at least for the desktop side, although most building bricks are there since we implement posix permissions model and we will probably base our multiuser system on that. But I don’t think we should use that for security, so there will not be hundreds of “fake” users for each system service. Just one user per, you know, user of the system, and each of these either is or is not in the “administrator” group (allowing to install apps in /system and generally mess things up in the system directory).
1 Like
Always referring to a modern vision of what on unix is convenient in my opinion, that you use different partitions you could create sandbox zones, bubbles accessible only through api to the various applications that share data between them.
The fact remains that in my opinion, partitions are still a valid tool, if you need to repair, migrate, restore only certain areas of the system, In my opinion they are not a hack, they are a brilliant thing and still valid now. The multiuser instead, which is something different, is inconvenient and should be overcome. The fucking password account system should also be overcome (in this case I am referring to things that go beyond Haiku, and that extend to the web), I don’t know how it could be overcome, I just know it has become a nightmare by now. 
While Haiku is a single user OS and I think it should stay that way, multi-user support would be nice. What I mean by “multi-user” is there can be multiple user accounts in Haiku but only one user can be active at a time.
Some of the old Live Linux distributions on CD-ROM could be booted and when you logged into the default user account, you could not only write to the $HOME directory but you could also install packages. What if something similar could be done with Haiku? The initial OS installation would become Read-Only and when a user logs into Haiku, their Writable file-system is overlay-ed on top of the Read-Only OS. This approach would allow each user to customize their usage of Haiku without impacting the other users. Nor could they access other user’s Writable file-system.
How would two user accounts share data? Perhaps a separate partition could be used. This implies a there is an “Opt-In” or a “shared” flag to allow all users to write directly to that file-system.
How would you update the OS? From a application tester point of view, it would be nice to have one user account for the unmodified OS install and another user account with various OS updates. So having OS updates installed on the user’s Writable file-system would work. However, if there is an OS update that adds/fixes hardware support, ensuring all user accounts have the OS update would be a problem. In this case, tools like SystemUpdater can overwrite the “Read-Only” OS as needed. And since Haiku can boot to a previous installation, updating the Read-Only OS files is the better choice.
This multi-user approach may not be the best or even practical, but hopefully others could help improve on the ideas or be inspired to think of other approaches to this topic.
1 Like
Putting a little order with everything that has been said so far, we could all deduce that more or less we all agree with these basic concepts.
Multi user, it may be useful, but not in the form that other operating systems are abusing it.
It could be useful when they are real users, and possibly, for security reasons, to allow the log-in of only one session at a time, taking into account that haiku is an os for desktop or client side use. Having said that, creating a multi-user system becomes much easier, essentially it involves creating and directing a “home” folder containing all the personal data and personal settings of the applications for each individual user, in addition a level of securityand privacy for each user should obviously be created .
For all the rest we need a modern system of protection of system files, which takes as a strong example the method of different partitions for each level, such as a system level (read only plus armored), an application level (read only but with a possibility to access it in writing more simplified), a general data management level, a personal data management level, so on … such a method remains valid, for a matter of ease of data transfer and recovery of system portions …
Personal applications that are installed in their isolated sandboxes and that can communicate with other applications through API.
Finally, the root level, this must not be considered as a user, essentially the root level must be considered as a use of the system without the armoring of the parts inaccessible to those parts of the system and armored folders, essentially with the root level it must be able to be done what Haiku is already now, where you can do everything, including self-destruct the system.
2 Likes
When you run any kind of software on your computer that you didn’t write yourself, you are basically granting the developer of said software access to all your files. If you don’t have any kind of segmentation of memory or files, then you end up in the same situation as Amiga Workbench, where any software had complete access to anything. The Amiga was plagued with malware and there really wasn’t a good way to protect it against it. I take it that Haiku has Memory protection for this reason. This is a basic feature of any multitasking operating system. Likewise userspace needs to have segmentation of files, otherwise any application can just embed malware into system libraries. It doesn’t have to be user segmentation, it can be some other kind of containerization or limitation. But it is just as much, a basic part of multitasking OS, as memory protection.
multi user is a idea from timeshare computing mainframe systems.
Agreed.
Today most of haiku users are passionate and cautious, being perfectly aware they’re dealing with a stable OS, altough beta, but I’m almost horrified by dreaming lots of kids accessing their parent’s haiku PCs and popping up on this forum crying “I only moved 100 random files icons, now the PC doesn’t boot anymore, why” ?
Hello everyone,
I have just discovered Haiku, and got fascinated by it after watching a couple of Youtube videos about it. So I am totally new to this forum and about to give Haiku a try. Still, I hope you don’t mind that I am adding my 0.02 EUR here already, although I am currently a total newbie to Haiku. I’ll try to keep it simple and short.
So, without further ado, here’s what I think about the topic about multi-user support in Haiku, or not, based purely on my own personal use cases.
- A minimum of access control, such as a login with username and password is a must-have for me. As long as Haiku is running virtualised, it’s not a big deal, of course. But I am thinking of installing it on an older laptop. In that scenario prevention of unauthorised access to system, applications and data is simply a requirement.
- Support for multi-factor authentication and pass-keys would be great (maybe for a future release), as an alternate option to user name and password.
- Full disk encryption would also be not just nice-to-have, but required on a laptop on travels.
- I have no urgent need for full multi-user support, in the sense that
a) multiple human users can have accounts on the system and/or that
b) multiple human users can have simultaneous sessions on the system.
I’d welcome support for these features, for sure, in a future release, but it’s nothing I’d need immediately or in R1, though.
Keep up the great work!
4 Likes
Hello and welcome to Haiku, on multiuser issue there has been many talks already (you can find them searching the forum here, in short, not in the pipeline so far (main devs can explain this better 
).
1 Like
Please don’t make me keep a password that I need to remember to unencrypt my disk.
I use Haiku on a dedicated machine. I also have an iPhone. The one reason I love my iPhone, is that perfectly working thumbprint to unlock the phone. Yes, I know the newer iPhones use FaceID, but they also got rid of the “button”, which was a huge mistake.
If we were to implement multi-user accounts, disk encryption, and a well thought out multi-session scheme, could we please not make the user have to remember a password…
These days, if an App or Site on my phone makes me have a user account with a password, I just ditch the idea immediately and move on to something else.
so is the “password”
With encryption? No. That’s just not possible with biometric authentification.
Not even on the iPhone you mention above, instead it will use a passcode or passphrase for the actual encryption and release it to the OS if you authenticate biometrically (that is why you need to type your pw/code when rebooting the phone)
The reason for this is that encryption and decryption only works with the precise password, that is mathematically it can only work if this is an exact match, biometric authentification cannot provide this, fingerprints slightly change, so does your face and even the iris changes, e.g by dilating. You are extremely unlikely to ever gain the exact same sensor data from these sources for a decryption.
So that leaves basically two options, the first is to Do it like the iPhone, ask for a pw at boot and use biometrics afterwards. (although the iPhone uses a seperate chip for this, on a normal laptop you would be susceptible to an attacker reading the key from RAM) The second option is using a physical key for this instead of a password, it could be something like a yubikey, or something simpler like a usb drive with a specific file on it.
So TL;DR passwords for disk encryption is not something to annoy users with but mathematically required.
From a UI perspective I definetely agree though, linux constantly asks for a password for random stuff, and it has nothing to do with disk encryption. ;(
2 Likes