Haiku, eventually, will have to have some sort of user or application based security, preferably before it becomes too popular. I was just thinking that perhaps something a little different from (or perhaps in addition to) the traditional user/file permissions setup would be nice. Right now most Linux users (AFAIK) and some Windows users have a restricted account that they use for their daily work and an administrative account for when they want to make system wide changes. I personally have tried this and, while I think it’s a good idea, O find it quite annoying in practice (installing applications for instance, since I, like many desktop users, do that quite often). It also lets any executable you install have full run of either your personal files (home directory) or the system (if it runs with additional permissions).
Ideally a program wouldn’t have access to anything it didn’t need. For instance, Firefox could have Read-only access to its application directory and read-write access to /boot/home/config/Mozilla/Firefox, and absolutely nothing else. That way, if a serious Firefox exploit was every found then all it could possibly do is mess up Firefox, if that. You can sorta do this by creating a new user account for each program, but that doesn’t seem managable or elegant. I’d prefer to simply have an executable’s permissions included in its file attributes. Interpreters (like perl or bash) would have to have essentially full permission by themselves, but when running a script they should inherit its permissions (so a script could make files in its directory and any subdirectories, but not the parents unless you explicitly add that privilage).
Perhaps internet access should also be restricted in the same way (can’t access the net, can only access update.softwarecompany.com, only outbound, etc.). Even application to application communication could be restricted (so an unprivilaged program can’t use a privilaged program to do stuff that it can’t normally). That way, a user could do anything they wanted, but their applications could only do what the user allowed. For instance, an image editor could access its own directory and something in /boot/home/config, but nothing else by default. If it tried accessing the internet a dialog could popup asking if it’s ok to give it that privilage (with the standard allow once, always allow, always block without asking, etc.), or if it wanted to access, say, /boot/home/Pictures (or perhaps read-only access to the whole drive except /boot/beos).
The idea is similar to a program I used to use that was made by eSafe for Windows 98 (I don’t think it’s availible anymore or works in later versions of Windows). Such an implementation wouldn’t even require applications to be multi-user aware (so better legacy support) or even that the system be multi-user. Later, if multi-user support is added then user-specific permissions could also be added as attributes (like giving Baron/root/administrator/whatever permission to open text files in /boot/beos in text editors).