Valid point. I thought about this, for system apps you would be able to assign lasting permission requests to read/write/modify anything., by default -- so it w

Valid point. I thought about this, for system apps you would be able to assign lasting permission requests to read/write/modify anything., by default -- so it would work as right now. Just like in browsers, permissions (permission type prompt) could be remembered in a cache. If you're not comfortable with giving any command full reign on your system, you could simply give granular, temporary permissions as required. A concept I find useful is that there are two kinds of security: -- Accidental security -- Malicious security Permissions help with both. Not only you don't want 3rd parties to invade or disrupt your system, you don't want users to invade or disrupt your system (or their own systems) accidentally. A classic example I believe is an user wanting to delete all files in current directory, typing $ sudo rm ./* and missing the dot, getting $ sudo rm /* #(delete *all files*) Ideally in this case you would see two different requests: > The command rf requests root access for file deletion at / > Accept? (y/N) > User's administrative password: or > The command rf requests access for file deletion at /home/user/cache/ > Accept? (Y/n) Note you're not prompted for password in the second case because you already have permissions for this operations (only the process 'rf' doesn't). You may not be particularly worried about malicious security for system programs, but even professional administrators could be worried about accidental security and best practices (if they're not they could easily select persistent full permissions). I get the impression the last thing e.g. sysadmins want is mess up production systems, and wouldn't mind a few more prompts when doing things manually (which should be rare?), or assgining scripts the exact permissions needed for their job.