The Unix permissions convention of root:group:user is IMO no longer really adequate for the security issues we’re facing at this point, and should probably be replaced with a convention of root:usergroup:user:exegroup:executable.

The evolution I propose changes the structure of file permissions to keep track of a program/program group having privileges over that file, and gives the users access to tools for administering the privileges of programs/program groups running under their own login.

Regulating privs by root:group:user was the right answer when the only thing we really needed to protect was the system integrity, and the question was simply “whom can we trust?”

But that’s no longer the case. Users (not just root) now value system integrity mainly (or only) because system integrity is necessary to protect assets far more valuable to them than the system itself.

But, while necessary, it is not sufficient. The primary threat to those assets comes not from other users, but from software running under their own account, with their own privileges, that does things using their privileges which they did not anticipate and would not approve of that software doing.

The trust issue between individual users’ assets and the privileges given the executables that they run is now as severe in terms of preventing losses to individual users, as the trust issue between system integrity and the privileges accorded individual users.

Accordingly, I think a future evolution of Unix probably ought to have users able to control delegation of their privileges to executables running under their login, in exactly the same way that root controls the delegation of privileges to user accounts.

So, a user who has just downloaded “SOOPERGAME.SWF” may have no problem with it having privileges to read and write in its own directory in his home folder, but has no real reason to trust its authors and absolutely would not give it the ‘executable group membership’ or however this works, that it would need to read/write in his customer database, mail spool, or bitcoin wallet.

Which would mean that securing operations should check the privileges of both user (to be sure the user has the authority from root) and the executable (to be sure that the executable has the authority from the user) before allowing an operation.