Unable to change ACL-permissions for symbolic links

Strange, 'chmod -?' shows the '-h' as valid, but 'man chmod' on Leopard does not document the parameter. I wonder if it is really supported?

Well, I think it should work, but 'man chmod' under Terminal on my system does not show the option.

BTW, chmod behaves the same on my system as what you describe.

Message was edited by: xnav

FYI, man chmod on my machine shows:

CHMOD(1) BSD General Commands Manual
NAME chmod -- change file modes or Access Control Lists

<snip>

DESCRIPTION
The chmod utility modifies the file mode bits of the listed files as specified by the mode operand. It
may also be used to modify the Access Control Lists (ACLs) associated with the listed files.

The generic options are as follows:

-f Do not display a diagnostic message if chmod could not modify the mode for file.

-H If the -R option is specified, symbolic links on the command line are followed. (Symbolic
links encountered in the tree traversal are not followed by default.)

-h If the file is a symbolic link, change the mode of the link itself rather than the file that
the link points to.

<snip>

BSD July 08, 2004

OK, any idea why my man page would be incorrect or how I could reload the pages?

NAME
chmod -- change file modes or Access Control Lists

SYNOPSIS
chmod [-fv] [-R [-H | -L | -P]] mode file ...
chmod [-fv] [-R [-H | -L | -P]] [-a | +a | =a] ACE file ...
chmod [-fv] [-R [-H | -L | -P]] [-E] file ...
chmod [-fv] [-R [-H | -L | -P]] [-C] file ...

I have no idea, but http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/chmod.1. html shows what mine does.

apfelfresser wrote:
the chmod-manual page states about the -h option: If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to.

But somehow this doesn't seem to have an effect. it always manipulates the original file instead of the symbolic link

OK, this is a well-known bug in FreeBSD, at least older versions, which carried over into Darwin.

But, it was at least partially fixed in 10.4, if you issued the command as root. See for example RE: issue with chown -h and symlinks on 10.3.9 and the rest of that topic. I haven't really looked at this since then.

There were some more interesting topics discussing this (before the fix) but they all seem to have been archived now. Basically these system calls were not initially implemented in the BSD kernel: lchflags(2), lchmod(2), lchown(2), lutimes(2). However the all important lchown(2) is present in 10.5 (as it was in 10.4):

macbook:/ root$ nm -x mach_kernel | grep lchown
001e438e 0f 01 0000 0003c4ae _lchown

as Michael showed, in the nm output. lchmod isn't implemented in the Darwin kernel.

Also, there is no manpage for lchown. but it's referenced by the following manpage.

[symlink(7)|http://developer.apple.com/documentation/Darwin/Reference/ManPages/m an7/symlink.7.html#//apple_ref/doc/man/7/symlink]

And a quick look at the kernel

andya Macintosh:/:111> nm -x /mach.sym | grep chmod
001d9f6a 03 00 0000 000240bb _chmod
001d9e09 03 00 0000 000240c2 chmodextended
001da1e6 03 00 0000 00027527 _fchmod
001da084 03 00 0000 0002752f fchmodextended

The only reference to the lchmod that I was able to find in the kernel source was
in the "bsd/sys/stat.h" file:

int lchmod(const char *, mode_t);

But this prototype is all that there is. The function isn't defined. There is also a reference to the function _lchmod in the dynmaic library that chmod(1) is linked to:

/usr/lib/libSystem.B.dylib
000abe87 0f 01 0000 00008925 _lchmod

So it appears that OS X still doesn't support changing the permissions/mode of a symbolic link.

..." So it appears that OS X still doesn't support changing the permissions/mode of a symbolic link."...

' chmod -h' is working here (for permissions, but not ACLs) and I'm pretty sure it was working in Tiger - but permissions on symbolic links seem to be irrelevant anyway.
Eg:<pre>
$ echo blah > file
$ ln -s file link
$ ls -ln file link
-rw-r--r-- 1 502 502 4 Mar 15 00:20 file
lrwxr-xr-x 1 502 502 4 Mar 15 00:20 link -> file
$ chmod -h 700 link
$ ls -ln file link
-rw-r--r-- 1 502 502 4 Mar 15 00:20 file
lrwx------ 1 502 502 4 Mar 15 00:20 link -> file</pre>

So ' chmod -h' works in principle, but eg.:<pre>
$ chmod -h 0 link
$ ls -ln file link
-rw-r--r-- 1 502 502 4 Mar 15 00:20 file

ls: link: Permission denied
l--------- 1 502 502 4 Mar 15 00:20 link
$ cat link
blah</pre>

I never did understand that.

But getting back to the original problem, there is something strange going on here. From the command line, I can't manipulate ACLs on symbolic links at all. Whether using ' chmod -h or setting inherit rules on a folder then creating a link, I can't generate a symbolic link with an ACL.

However, "Finder" apparently can. So to remove ACLs from a symbolic link, the only workaround I can see is to remove them from the parent folder if applicable, then use "Get Info" to apply the folder's permissions/ACLs to "enclosed items".

Edit: Sorry, I got that backwards - "Get Info" can transfer ACLs from a folder and add them to enclosed symbolic links, but it doesn't seem to remove them...

$ ls -ln file link
-rw-r--r-- 1 502 502 4 Mar 15 00:20 file
ls: link: Permission denied
l--------- 1 502 502 4 Mar 15 00:20 link
$ cat link
blah

I never did understand that.

Are you referring to the "Permission denied" message. the permissons on the symlink are preventing you from reading the symlinks contents, which is the name of the file that it's linked too. Notice that it's missing the '-> file' bit.

Message was edited by: Nils C. Anderson

Ok, I take back my edit - "Get Info" can transfer a state of lacking an ACE from a parent folder to "enclosed items", including symbolic links. But for reasons that aren't clear to me, on my system it sometimes skips items, leaving them intact...

Thanks. Actually, what seems strange to me is that despite the link "link" having a mode of "0", it is possible to follow it, and to ' cat' the original file.

I recognize that I do have "read" privileges for the original file "file", but what's the point of having (and by extension, modfying) permissions on a symbolic link if the permissions don't seem to do anything?