Recently debugged my way out of a strange Unixy problem.
I administer a shared server for a prior job. There's some shared webspace that I setup in a hurry, and a few weeks ago modified the permissions to let everyone in a group affiliated with a certain project update the webspace. Simple -
- cd /var/www/
- chgrp -R groupname html_project
- chmod 2775 html_project
- find html_project -type f -exec chmod 664 \{} \;
- find html_project -type d -exec chmod 2775 \{} \;
I spent considerable time staring at the permissions, making sure I was indeed in the right grup ... and then began the horrible process of doubting myself. Do groups actually work the way I think they do? Do I need to login to groups using newgrp to get the right permissions? No, that can't be it .. but there's the hard reality of "permission denied". What's going on? I don't see any ACLs, nor any ext4 attributes that should interfere.
Logged out again, then did the "id" command to look at the groups a different way ... oh, wait a minute! Eyeballed the number for that group, and it's different than what I spotted in /etc/group ... after that I quickly unraveled the problem - two entries in /etc/group with the same name but different gids, and I was in the latter but the files group-belonged to the former. (take-home lesson: DO NOT DO THAT!) .. Unix uses gids and uids internally - the names we see with various utilities are just user-friendly conveniences. Solution: rename the later group to something distinct (previously it was the name of the owner of the project, so I tacked "lab" after that), then a bit more "chgrp -R", and all is good!
The other take-home lesson is that oddly-formed files for basic authentication stuff can be hard to debug. I've encountered problems vaguely like this before; the first few times took me a lot longer.
Also, pleased that my faith in my knowledge of how Unix permissions work doesn'tneed to falter.
