Permissions Symlink – How to Change Symlink Permissions

permissionssymlink

I have a issue: I need to change the permission of the symlink from 777 to 755 and I do not have any idea how should I do it. I have tried using the chmod command but it's not working.
I want

lrwxrwxrwx  1 frosu  2016_cluj     5 Jul  4 13:53 test6 -> test0

to

lrwxr-xr-x 1 frosu  2016_cluj     5 Jul  4 13:53 test6 -> test0

Best Answer

Some systems support changing the permission of a symbolic link, others do not.

  • chmod -- change file modes or Access Control Lists (OSX and FreeBSD, using -h)

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

  • chmod - change file mode bits (Linux)

    chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals.

Since the feature differs, POSIX does not mention the possibility.

From comments, someone suggests that a recent change to GNU coreutils provides the -h option. At the moment, that does not appear in the source-code for chmod:

  while ((c = getopt_long (argc, argv,
                           ("Rcfvr::w::x::X::s::t::u::g::o::a::,::+::=::"
                            "0::1::2::3::4::5::6::7::"),
                           long_options, NULL))

and long_options has this:

static struct option const long_options[] =
{
  {"changes", no_argument, NULL, 'c'},
  {"recursive", no_argument, NULL, 'R'},
  {"no-preserve-root", no_argument, NULL, NO_PRESERVE_ROOT},
  {"preserve-root", no_argument, NULL, PRESERVE_ROOT},
  {"quiet", no_argument, NULL, 'f'},
  {"reference", required_argument, NULL, REFERENCE_FILE_OPTION},
  {"silent", no_argument, NULL, 'f'},
  {"verbose", no_argument, NULL, 'v'},
  {GETOPT_HELP_OPTION_DECL},
  {GETOPT_VERSION_OPTION_DECL},
  {NULL, 0, NULL, 0}
};

Permissions are set with chmod. Ownership is set with chown. GNU coreutils (like BSD) supports the ability to change a symbolic link's ownership. This is a different feature, since the ownership of a symbolic link is related to whether one can modify the contents of the link (and point it to a different target). Again, this started as a BSD feature (OSX, FreeBSD, etc), which is also supported with Linux (and Solaris, etc). POSIX says of this feature:

-h
For each file operand that names a file of type symbolic link, chown shall attempt to set the user ID of the symbolic link. If a group ID was specified, for each file operand that names a file of type symbolic link, chown shall attempt to set the group ID of the symbolic link.

So much for the command-line tools (and shell scripts). However, you could write your own utility, using a feature of POSIX which is not mentioned in the discussion of the chmod utility:

int chmod(const char *path, mode_t mode);
int fchmodat(int fd, const char *path, mode_t mode, int flag);

The latter function adds a flag parameter, which is described thus:

Values for flag are constructed by a bitwise-inclusive OR of flags from the following list, defined in <fcntl.h>:

AT_SYMLINK_NOFOLLOW
If path names a symbolic link, then the mode of the symbolic link is changed.

That is, the purpose of fchmodat is to provide the feature you asked about. But the command-line chmod utility is documented (so far) only in terms of chmod (without this feature).

fchmodat, by the way, appears to have started as a poorly-documented feature of Solaris which was adopted by the Red Hat and GNU developers ten years ago, and suggested by them for standardization:

According to The Linux Programming Interface, since 2.6.16, Linux supports AT_SYMLINK_NOFOLLOW in these calls: faccessat, fchownat, fstatat, utimensat, and linkat was implemented in 2.6.18 (both rather "old": 2006, according to OSNews).

Whether the feature is useful to you, or not, depends on the systems that you are using.

Related Question