457487 - SetPermissionsOfLink sets permissions on link target on UNIX systems

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Josh Aas]

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.

Comment 1

[Josh Aas]

Attachment: fix v1.0

Comment 2

[Josh Aas]

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 3

[Steven Michaud [:smichaud] (Retired)]

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

Comment 4

[Josh Aas]

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.

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Doug Turner (:dougt)]

i agree.  the current implementation is very wrong.

Comment 7

[Josh Aas]

Attachment: fix v1.1

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.

Comment 8

[Doug Turner (:dougt)]

Comment on attachment 341048 [details] [diff] [review]
fix v1.1

this is what we discussed.  Please post something to the newsgroup regarding this change.

Comment 9

[Josh Aas]

landed on trunk