Yeah.. I'm sitting here wondering how many years would it take to remove equally stupid error that says 'private key permissions too open' from ssh-add and friends.
Would save me a wrapper script on my flashdrive that does hacks like loading it from stdin or moving it to temp file.
They're elegant at first glance, it's just the attack surface of "exec this other program" turns out to be enormous. eg. You wouldn't necessarily think that you'd have to clean out all environment variables, but what if your program is linked to some library that tries to parse some obscure environment variable and that parser has a bug. And the list goes on.
The alternative is sending messages to daemons, but as it turns out, the attack surface of those is pretty large too, albeit not as large as setuid.
The whole "do some work on my behalf with elevated privs" is not exactly a solved problem in Unix.
Imagine if you wanted to enter a bank safe, but your key doesn't fit the lock. If you were able to change the lock, you would bypass the lock mechanism, rendering it useless
I think a more appropriate question would be, if the key fits, couldn't you change the lock?
Maybe, that would give you 3 abilities.
1 Lock yourself out if you please? Not terrible
2 Provide access to others, which makes sense since you already have access to the file, you could theoretically share it through other channels, you naturally cannot prevent this.
3. Lock others out. This one is less of a security risk and more of a nuisance risk.
I think the unix model is simple, maybe selinux offers more sophistication. That said the unix chown behaviour could have gone either way in terms of security, but in terms of design it makes sense as is.
In this analogy, I think the analogue of the owner of the bank safe is the owner of the file. Unless you're envisioning the bank safe as representing all the files, rather than just one ...?
Would save me a wrapper script on my flashdrive that does hacks like loading it from stdin or moving it to temp file.