search

andsens / homeshick

git dotfiles synchronizer written in bash
MIT License
2.11k stars 145 forks source link

symlinked items don't preserve file permissions #92

Closed varemenos closed 10 years ago

varemenos commented 10 years ago

The file that get symlinked from a castle don't preserve their file permissions (for example one of my file had "600" but it got turned into "777")

ps: sorry for creating so many issues in such a short time but I'm really loving the idea behind homeshick and I just can't enjoy it enough while these "bugs" exist.

squaresurf commented 10 years ago

I've experienced this issue as well. I have my ~/.ssh/config file in a castle and whenever I edit it it breaks my ssh since I need to chmod it to 600. I'll look into this and see if I can fix it.

andsens commented 10 years ago

The file that get symlinked from a castle don't preserve their file permissions (for example one of my file had "600" but it got turned into "777")

Well, yeah. :-) Symbolic links don't need permissions in and on themselves. They are only pointers, so whatever permissions are set on the original file, will be preserved when accessing the symlink, you just can't see those permissions when you run ls on the symlink.

I just can't enjoy it enough while these "bugs" exist.

Airquotes indeed. So far you haven't reported any bugs :-)

varemenos commented 10 years ago

whatever permissions are set on the original file, will be preserved when accessing the symlink

Some CLI tools don't see it that way, for example the ssh key agent on linux distros (like Ubuntu and Fedora). Because of the symlink's 777 permissions the agent ignores the key

squaresurf commented 10 years ago

This sounds like a similar issue I had with the ssh config. It ended up being an issue with git and not homeshick. See if something like this would fix your key issues: https://github.com/andsens/homeshick/pull/93#issuecomment-40957942

andsens commented 10 years ago

Some CLI tools don't see it that way, for example the ssh key agent on linux distros (like Ubuntu and Fedora). Because of the symlink's 777 permissions the agent ignores the key

That's just not true. I tried it out 5 minutes ago (on debian, which runs the same openssh every other distro does), something else must be wrong on your setup (maybe your .ssh/ is world writeable).

p.s.: If this really were the case, enforcing the permissions would make no sense at all. They are enforced to make sure that nobody but you can change the contents of e.g. the authorized_keys file, what good do the permissions of the symlink do in that case? They have no say in whether you can read, edit or execute a file.