In nsLocalFileUnix.cpp, SetPermissionsOfLink is implemented by just calling SetPermissions, which always acts on link targets via chmod. It should act on the link itself via lchmod.
Summary: SetPermissionsOfLink is wrong on UNIX systems → SetPermissionsOfLink sets permissions on link target on UNIX systems
We have to check on the availability of lchmod, it doesn't exist on Mac OS X before 10.5 (not relevant here, just saying) and I think there are at least some recent versions of Solaris that don't support it. I think BSD and Linux versions that we'd be concerned with have lchmod, and Solaris ignores the permissions of symlinks (basic googling), so perhaps we can just ifdef and return NS_OK for Solaris.
Comment on attachment 340762 [details] [diff] [review] fix v1.0 Josh, you (probably) shouldn't use lchmod(). When I compiled a simple test program on my Linux box (Ubuntu 7.10) that used lchmod(), I got the following warning: warning: warning: lchmod is not implemented and will always fail
Attachment #340762 - Flags: review?(smichaud) → review-
Whoa, I didn't get that at all. I'll figure out the story there. We should at least be doing nothing instead of incorrectly mucking with the link target.
Are there file systems where symlinks *can* have permissions? I've never heard of such a thing. AFAICT we'd be better off throwing a NOT_IMPLEMENTED exception in all cases.
i agree. the current implementation is very wrong.
Fine with me - I'm only really interested in not targeting the wrong file. We can sort out implementing this in another bug if people want.
Attachment #341048 - Flags: review?(smichaud) → review+
Comment on attachment 341048 [details] [diff] [review] fix v1.1 this is what we discussed. Please post something to the newsgroup regarding this change.
Attachment #341048 - Flags: superreview?(doug.turner) → superreview+
landed on trunk
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.