severity 10311 wishlist thanks Jan Engelhardt wrote: > Give chmod a "-h" option as well
There are several important points concerning symlinks, the mode bits, chmod(1) and chmod(2). * The mode bits of a symlink are not used. The original Unix authors ignored them and did not provide any way to change them. * The mode bits of a symlink are set when they are created and never modified nor used after that time. * Some operating systems do allow symlink mode bits to be set but that feature is not wide spread. Since the mode bits of a symlink are not in any way significant there isn't any urgent need to change them. The displayed value is completely cosmetic and without function. This is an FAQ. http://www.gnu.org/software/coreutils/faq/#How-do-I-change-the-ownership-or-permissions-of-a-symlink_003f > chown(1) has a -h option by which it affects symlinks directly rather The chown(1) command can do this because the lchown(2) operating system call exists which provides that functionality. But there isn't any equivalent lchmod(2) function call. If an lchown(2) system call were to exist then adding an option to chmod(1) would be possible. I have always considered this inconsistent that lchown(2) exists without lchmod(2) existing. But I was not consulted in the implementation. Likewise creat(2) is missing the 'e'. It is just the way things are. A small number of those inconsistencies must be accepted after 40 years of use. The ability to set the mode bits of a symlink have never been implemented without the lchmod(2) system call because in order to change the mode bits of a symlink it would be necessary to remove the previous one and then create a new one with the desired mode bits by specifying the umask at time of creation. This would have other serious negative side-effects not commensurate with the cosmetic value of the display of the mode bits since the mode bits are never used. The ownership and group would then be that of the creating process. There would need to be special care taken such that at no time would any other process find that the symlink had been removed during this removal and creation process. > Attempting chmod -R g+w /home/groups/evilgroup is still a risk, and > would necessity a more long-winded command involving find(1). It > would therefore be welcome that chmod receive an -h option that just > skips over them (besides perhaps attempting to change their > permissions as well). I am sorry but I did not understand the problem you are describing in this text. Neither chmod -R nor find by default dereference symlinks. Try using chmod's -v option to have it emit messages concerning actions taken or actions not taken. I think the output is useful. Bob
