Re:I saw a different problem (Score 1)

In your scheme of things, how do you propose to let multiple users have access to the same program without duplicating the binaries?

There's no reason to duplicate binaries. Multiple users can access a single program binary, just as we do now. Anyone logged onto my current computer can run Internet Explorer, and there is only one binary for it. Unfortunatly, any program run by any user can probably modify the binary... but that's current OS design.

Putting programs together in the same location as data files has, in part, been the cause of the current permissions mess on Windows.

No, that's rediculous. Perhaps program + SHARED data files in same folder is a bad idea... but that's not what I'm suggesting. I am suggesting that a program has WRITE access only to its own folder. Its that simple. Meanwhile, access is further restricted to files/folders therein that are OWNED BY the current user.
Programs in the past were not designed for multiple users; that was the problem. The new convention, given the understanding that the program only has access to its own folder, is that when a program starts up, it creates a "data_*" folder and a "*.settings" file in its own folder, where * is the name of the currently logged on user. No other programs, and no other limited user accounts can access the "data_*" folder or "*.settings" file. When run as a different user, the program will not attempt to access them, since its looking for a folder whose name is based on the current user's unique login name, and even if it wanted to... it couldn't access them because the new user would not own them!

In summary, under my configuration, a "PROGRAM" is an isolated entity on the system. There is a single copy of it, it can only write to its own folder -- to files and folders owned by the current user -- and by convension, it looks for a data folder unique to the logged on user.

Also, putting data files in the same folder as the program that created them makes perfect sense. If a program only knows how to WRITE file format "X", then it should not have WRITE access to EVERY OTHER FILE on the system. This simplifies things considerably. For example, reguardless of file-associations, which are only useful to Windows Explorer anyway, a program can access any file it created (owned by the current user in the programs own directory). The program should not be changing files it has no business accessing, such as files it didn't create, files not owned by the current user, and files outside its own directory. And it should be reading from files outside its directory that it hasn't been explicitly granted read-access to by the user.

With such isolation, a newly installed program cannot harm your existing data files; all it can do is sit in its own folder and play with itself. Antivirus software that embeds itself in your OS will no longer be necessary. In fact, any program that embeds itself in your OS will be unnecessary. The OS has a modular design where any program can be downloaded and safely run. This OS knows how to keep any program in check! If any program gets out of hand (maybe it's using APIs to change your desktop background or move your mouse all around) you can press a button for a Program Manager that immediatly cuts off all program access to input devices, and allows you to kill the annoying program.

Along with the need to limit programs from accessing data they should not be accessing, there is a need to prohibit limited-privileged user accounts from modifying program binaries and resources. What we probably need is some combination of your suggestion along with current practices in various UNIX flavors (which have addressed the issue I raised, BTW).

Not really, my solution is fine. You're still thinking in terms of current system configurations. Under my configuration, how can a person "modify" a binary? The short answer is that they can't, because they'd need ANOTHER PROGRAM to do it; however, other programs do not have WRITE access to the binary, unless the user moves the binary into that application's own folder where it actually has write access to the file! If the user doesn't OWN the binary... then he or she can't move it, and even if he or she could, no program could modify the file unless the user owns it! If an administrator installs a program, its safe. It's that simple.

Specifically, your idea of limiting access to user data files even within a user's home directory is a good idea, but the mapping between a program and the data it can access, should not be as simple as "if it is my descendant in the directory hierarchy, I can access it".

I disagree. It should be that simple. What I said was that a program should have WRITE access only to its own folder, and files and subfolders therein which BELONG TO THE CURRENT USER. It can have READ access to whatever folder the user grants it permission to access. Forget the UNIX "home" directory. Like windows, files in a single folder can have different owners.

- - - - - - - - - -
Problems solved:
--Complex registry no long exists.
--Viruses impossible.
--Expoits possible (in p.o.s. programs), however effects go no further than the directory of the p.o.s. program being exploited (so even if sheepishly does anything the internet tells it to do, the OS totally keeps it in check).
--OS file manager doesn't display files that you don't own or can't access. Such files are untouchable through OS utilities or any running programs. Executable files are visible to everyone, and ALWAYS safe to run.
--Program installation is a breeze. Any user may install a program, BECAUSE IT's SAFE NOW!!! Simply pass a zip file to the OS, and it turns it into a directory owned by the current user. It identifies the executable, grants execution access to all users, and meanwhile the OS maintains a user-independent list of the files and folders installed, so the executable has permission to access them regardless of the logged-on user (note that the files themselves may still be OWNED by an administrator, and remain safe from being moved, deleted, or copied). If the list is ever modified to point to files outside the program's folder, the OS halts access.

--A program and its settings are all in one spot. Easy to transfer and copy. Copy the directory... and all the files and folders therein that you own will be copied (must be owner to copy, move, or delete anything; if you don't own it, you can't touch it. Remember, OS maintains user-independent list of files installed with the program, so the program always has access to them... always in its own directory).
--Network user? Great! Screw roaming profiles, which inefficiently download settings for ALL programs. When you login on a domain as a specific user, some basic settings are loaded (desktop background etc.). A mapped remote drive has your programs and files, and everything functions normally... you can only access files on the drive that the servers knows you own, etc. You don't even have to install the program locally, and *.settings files are downloaded on an as-needed basis as a running program accesses them.

- - - - - - - - - -
Bottom line: by default, a program you download and run should not have WRITE access to every file on your computer, and certainly not read or write access to files you don't own.
Currently, if you download an application... you have to trust it... ooo scary FUD... cause it might be a virus, and you see.. that's rediculous, because if programs weren't allowed to access everything by default, you wouldn't have to worry. And now I see people using this as a scare tactic saying that if you download a pirated game, "it might have a virus". Well, if the damned program didn't have WRITE access to every file I own by default, then I wouldn't have to worry at all, would I. I wouldn't so long as the OS was designed to be secure, as I have outlined.