Morning all, I was running some deployment scripts on Friday night that kept failing because it prompted for a password for a user I was already sudo'd in as when trying to scp a file onto itself.
e.g.
on server 51.123.123.123 as sudo dlam
typing: scp testfile dlam@51.123.123.123:/tmp
prompts for a password
Turned out that it was because the home directory for dlam had been set as permissions 777 instead of 755. When they are 755 there is no propt for a password and everything works fine.
So a simple question, is this a bug, or is there a good reason for this?
Hi. I can understand the home directory not being writeable without permissions, but why would it need a password to write to a /tmp directory?
Is it just a blanket ban from being able to scp any files to any directory for a user with 777 permissions in the home directory just to make sure you can't do any mischief?
The authentication mechanism doesn't care what exactly you are trying to do; if you're not able to authenticate, you are not allowed in. It's more of an architectural issue than a philosophical stance, I guess (make authentication not depend on the later parts), but philosophically, too, it makes sense.
Thank for that. It was baffilling trying to work out what the problem was on a Friday night/Saturday morning - and even more baffiling to find the problem but not understand why it was a problem
