GNU bug report logs - #10311
RFE: Give chmod a "-h" option as well

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10311 in the body.
You can then email your comments to 10311 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jan Engelhardt <jengelh <at> medozas.de>
To: bug-coreutils <at> gnu.org
Subject: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 17:29:46 +0100 (CET)

Hi,


chown(1) has a -h option by which it affects symlinks directly rather
than the pointed-to file. The bonus side effect is that the
pointed-to files don't get changed in any way, which is kinda welcome
if you attempt to "fix" permissions/ownership in a directory where an
evil user could create a symlink to e.g. /etc/shadow.

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).

Message #8 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Jan Engelhardt <jengelh <at> medozas.de>
Cc: 10311 <at> debbugs.gnu.org
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 10:30:05 -0700

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

Message #13 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Jan Engelhardt <jengelh <at> medozas.de>
To: Bob Proulx <bob <at> proulx.com>
Cc: 10311 <at> debbugs.gnu.org
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 18:59:20 +0100 (CET)

On Friday 2011-12-16 18:30, Bob Proulx wrote:
>
>chmod -R [does not] by default dereference[s] symlinks.

It does not? Oh, in that case the report may be closed.

This behavior is however inconsistent with what chown (and many other
tools) do by default though.

Message #16 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>
Cc: 10311 <at> debbugs.gnu.org, Jan Engelhardt <jengelh <at> medozas.de>
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 10:06:40 -0800

On 12/16/11 09:30, Bob Proulx wrote:
> Neither chmod -R nor find by default dereference symlinks.

But there's still a problem without -R.  Suppose the attacker does
"ln -s /etc/passwd slylink" and then root does "chmod a+w *"
in a directory containing slylink.  Then anyone can write /etc/passwd.

There's an obvious fix here: make chmod act like chown with respect
to the -H, -L, -P, and -h options.  This would be compatible with
FreeBSD chmod.  On hosts that support symbolic-link permissions
(BSD being one of them), GNU chmod would act like BSD chmod when
changing the mode of symbolic links.  On hosts that don't, it
would report an error.  Then a paranoid root (and shouldn't root
be paranoid? :-) could use chmod -h for everything.

Here's a quick and untested patch to do this.  Assuming there's interest,
I can flesh this out by adding proper documentation and test cases.

diff --git a/src/chmod.c b/src/chmod.c
index 6fec84a..6b7c021 100644
--- a/src/chmod.c
+++ b/src/chmod.c
@@ -68,6 +68,10 @@ static mode_t umask_value;
 /* If true, change the modes of directories recursively. */
 static bool recurse;
 
+/* 1 if --dereference, 0 if --no-dereference, -1 if neither has been
+   specified.  */
+static int dereference = -1;
+
 /* If true, force silence (suppress most of error messages). */
 static bool force_silent;
 
@@ -87,7 +91,8 @@ static struct dev_ino *root_dev_ino;
    non-character as a pseudo short option, starting with CHAR_MAX + 1.  */
 enum
 {
-  NO_PRESERVE_ROOT = CHAR_MAX + 1,
+  DEREFERENCE_OPTION = CHAR_MAX + 1,
+  NO_PRESERVE_ROOT,
   PRESERVE_ROOT,
   REFERENCE_FILE_OPTION
 };
@@ -95,7 +100,9 @@ enum
 static struct option const long_options[] =
 {
   {"changes", no_argument, NULL, 'c'},
+  {"dereference", no_argument, NULL, DEREFERENCE_OPTION},
   {"recursive", no_argument, NULL, 'R'},
+  {"no-dereference", no_argument, NULL, 'h'},
   {"no-preserve-root", no_argument, NULL, NO_PRESERVE_ROOT},
   {"preserve-root", no_argument, NULL, PRESERVE_ROOT},
   {"quiet", no_argument, NULL, 'f'},
@@ -188,6 +195,7 @@ process_file (FTS *fts, FTSENT *ent)
   char const *file_full_name = ent->fts_path;
   char const *file = ent->fts_accpath;
   const struct stat *file_stats = ent->fts_statp;
+  struct stat stat_buf;
   mode_t old_mode IF_LINT ( = 0);
   mode_t new_mode IF_LINT ( = 0);
   bool ok = true;
@@ -232,10 +240,28 @@ process_file (FTS *fts, FTSENT *ent)
       break;
 
     case FTS_SLNONE:
-      if (! force_silent)
-        error (0, 0, _("cannot operate on dangling symlink %s"),
-               quote (file_full_name));
-      ok = false;
+      if (dereference)
+        {
+          if (! force_silent)
+            error (0, 0, _("cannot operate on dangling symlink %s"),
+                   quote (file_full_name));
+          ok = false;
+        }
+      break;
+
+    case FTS_SL:
+      if (dereference)
+        {
+          if (fstatat (fts->fts_cwd_fd, file, &stat_buf, 0) != 0)
+            {
+              if (! force_silent)
+                error (0, errno, _("cannot dereference %s"),
+                       quote (file_full_name));
+              ok = false;
+            }
+
+          file_stats = &stat_buf;
+        }
       break;
 
     case FTS_DC:		/* directory that causes cycles */
@@ -266,17 +292,16 @@ process_file (FTS *fts, FTSENT *ent)
       new_mode = mode_adjust (old_mode, S_ISDIR (old_mode) != 0, umask_value,
                               change, NULL);
 
-      if (! S_ISLNK (old_mode))
+      if (fchmodat (fts->fts_cwd_fd, file, new_mode,
+                    dereference ? 0 : AT_SYMLINK_NOFOLLOW)
+          == 0)
+        chmod_succeeded = true;
+      else
         {
-          if (chmodat (fts->fts_cwd_fd, file, new_mode) == 0)
-            chmod_succeeded = true;
-          else
-            {
-              if (! force_silent)
-                error (0, errno, _("changing permissions of %s"),
-                       quote (file_full_name));
-              ok = false;
-            }
+          if (! force_silent)
+            error (0, errno, _("changing permissions of %s"),
+                   quote (file_full_name));
+          ok = false;
         }
     }
 
@@ -381,6 +406,13 @@ Change the mode of each FILE to MODE.\n\
   -c, --changes           like verbose but report only when a change is made\n\
 "), stdout);
       fputs (_("\
+      --dereference      affect the referent of each symbolic link (this is\n\
+                         the default), rather than the symbolic link itself\n\
+  -h, --no-dereference   affect each symbolic link instead of any referenced\n\
+                         file (useful only on systems that can change the\n\
+                         ownership of a symlink)\n\
+"), stdout);
+      fputs (_("\
       --no-preserve-root  do not treat `/' specially (the default)\n\
       --preserve-root     fail to operate recursively on `/'\n\
 "), stdout);
@@ -389,6 +421,19 @@ Change the mode of each FILE to MODE.\n\
   -v, --verbose           output a diagnostic for every file processed\n\
       --reference=RFILE   use RFILE's mode instead of MODE values\n\
   -R, --recursive         change files and directories recursively\n\
+\n\
+"), stdout);
+      fputs (_("\
+The following options modify how a hierarchy is traversed when the -R\n\
+option is also specified.  If more than one is specified, only the final\n\
+one takes effect.\n\
+\n\
+  -H                     if a command line argument is a symbolic link\n\
+                         to a directory, traverse it\n\
+  -L                     traverse every symbolic link to a directory\n\
+                         encountered\n\
+  -P                     do not traverse any symbolic links (default)\n\
+\n\
 "), stdout);
       fputs (HELP_OPTION_DESCRIPTION, stdout);
       fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -414,6 +459,7 @@ main (int argc, char **argv)
   bool preserve_root = false;
   char const *reference_file = NULL;
   int c;
+  int bit_flags = FTS_PHYSICAL;
 
   initialize_main (&argc, &argv);
   set_program_name (argv[0]);
@@ -426,12 +472,33 @@ main (int argc, char **argv)
   recurse = force_silent = diagnose_surprises = false;
 
   while ((c = getopt_long (argc, argv,
-                           "Rcfvr::w::x::X::s::t::u::g::o::a::,::+::=::",
+                           "HLPRcfhvr::w::x::X::s::t::u::g::o::a::,::+::=::",
                            long_options, NULL))
          != -1)
     {
       switch (c)
         {
+        case 'H': /* Traverse command-line symlinks-to-directories.  */
+          bit_flags = FTS_COMFOLLOW | FTS_PHYSICAL;
+          break;
+
+        case 'L': /* Traverse all symlinks-to-directories.  */
+          bit_flags = FTS_LOGICAL;
+          break;
+
+        case 'P': /* Traverse no symlinks-to-directories.  */
+          bit_flags = FTS_PHYSICAL;
+          break;
+
+        case 'h': /* --no-dereference: affect symlinks */
+          dereference = 0;
+          break;
+
+        case DEREFERENCE_OPTION: /* --dereference: affect the referent
+                                    of each symlink */
+          dereference = 1;
+          break;
+
         case 'r':
         case 'w':
         case 'x':
@@ -499,6 +566,21 @@ main (int argc, char **argv)
         }
     }
 
+  if (recurse)
+    {
+      if (bit_flags == FTS_PHYSICAL)
+        {
+          if (dereference == 1)
+            error (EXIT_FAILURE, 0,
+                   _("-R --dereference requires either -H or -L"));
+          dereference = 0;
+        }
+    }
+  else
+    {
+      bit_flags = FTS_PHYSICAL;
+    }
+
   if (reference_file)
     {
       if (mode)
@@ -553,8 +635,8 @@ main (int argc, char **argv)
       root_dev_ino = NULL;
     }
 
-  ok = process_files (argv + optind,
-                      FTS_COMFOLLOW | FTS_PHYSICAL | FTS_DEFER_STAT);
+  bit_flags |= FTS_DEFER_STAT;
+  ok = process_files (argv + optind, bit_flags);
 
   exit (ok ? EXIT_SUCCESS : EXIT_FAILURE);
 }

Message #19 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 10311 <at> debbugs.gnu.org, Jan Engelhardt <jengelh <at> medozas.de>
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 10:42:29 -0700

[Message part 1 (text/plain, inline)]

On 12/16/2011 10:30 AM, Bob Proulx wrote:
> 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.

That's true for Linux, but false for BSD (where the mode bits of a
symlink can allow restriction on dereferencing through the symlink).

> 
> * The mode bits of a symlink are set when they are created and never
>   modified nor used after that time.

Linux cannot modify symlink mode bits, but BSD can, precisely because
Linux does not honor symlink mode bits, but BSD does.  POSIX permits
both styles of operation; the new fchmodat() API is required to
understand AT_SYMLINK_NOFOLLOW, but is allowed to reject it with
EOPNOTSUPP (compared to the more typical EINVAL for an invalid flag bit).

> 
> * 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.

Since BSD chmod can set and usefully use symlink mode bits, and GNU
coreutils can target BSD, then yes, we should support chmod -h, using
fchmodat(), even if it is not our highest priority to implement it.

At one point I had a scratch patch in one of my local trees attempting
this conversion to add chmod -h; maybe I should revisit it and submit it
to the list.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #22 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Jan Engelhardt <jengelh <at> medozas.de>
Cc: 10311 <at> debbugs.gnu.org
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 11:24:53 -0700

Jan Engelhardt wrote:
> Bob Proulx wrote:
> > chmod -R [does not] by default dereference[s] symlinks.
> 
> It does not? Oh, in that case the report may be closed.

Here is an example test case:

  $ mkdir symlink-perm-test
  $ cd symlink-perm-test
  $ mkdir dir1 dir2
  $ date > dir1/datestamp
  $ chmod go-w dir1/datestamp

  $ ls -ldog dir1/datestamp
  -rw-r--r-- 1 29 Dec 16 11:11 dir1/datestamp

  $ ls -ldog dir2/link1
  lrwxrwxrwx 1 17 Dec 16 11:12 dir2/link1 -> ../dir1/datestamp

  $ cat dir2/link1
  Fri Dec 16 11:11:10 MST 2011

  $ chmod -v -R g+w dir2
  mode of `dir2' retained as 0775 (rwxrwxr-x)
  neither symbolic link `dir2/linkdir2' nor referent has been changed
  neither symbolic link `dir2/link1' nor referent has been changed

  $ ls -ldog dir1/datestamp
  -rw-r--r-- 1 29 Dec 16 11:11 dir1/datestamp

> This behavior is however inconsistent with what chown (and many other
> tools) do by default though.

Symlinks violate some principles of least surprise. Therefore it is no
surprise that it is impossible to make all uses of symlinks
unsurprising.

Symlinks were intended to be completely transparent.  There shouldn't
be any difference between a symlink and the referenced file.  But some
commands do have differences anyway.

Bob

Message #25 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 10311 <at> debbugs.gnu.org, Jan Engelhardt <jengelh <at> medozas.de>
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 11:37:47 -0700

Eric Blake wrote:
> Bob Proulx wrote:
> > * The mode bits of a symlink are not used.  The original Unix authors
> >   ignored them and did not provide any way to change them.
> 
> That's true for Linux, but false for BSD (where the mode bits of a
> symlink can allow restriction on dereferencing through the symlink).

What?!  I was not aware of this.  I have been too SysV centric for too
many years.  And I do not have access to a BSD system in which to
learn about it.

It would be informative to myself and I expect others if you could
post an example of the behavior from a BSD system showing the
restriction through a symlink's permissions.

Bob

Message #28 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>
Cc: 10311 <at> debbugs.gnu.org, Jan Engelhardt <jengelh <at> medozas.de>
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 10:58:50 -0800

On 12/16/11 10:37, Bob Proulx wrote:
> an example of the behavior from a BSD system showing the
> restriction through a symlink's permissions.

In BSD systems a symlink's permissions do not restrict
anything.  They exist, and can be changed, and you can look
at them with ls -l, but they have no effect on what you can
do with the symlink.

I do recall an alternative implementation where you could
not use readlink without read permission to the symlink,
and you could not follow the symlink with search (x)
permission.  But I don't remember which one that was;
perhaps it was just experimental.

In NTFS symbolic permissions have a different interpretation,
which I don't know much about and may not be relevant here.

Message #31 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 10311 <at> debbugs.gnu.org, Jan Engelhardt <jengelh <at> medozas.de>
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 12:04:33 -0700

[Message part 1 (text/plain, inline)]

On 12/16/2011 11:37 AM, Bob Proulx wrote:
> Eric Blake wrote:
>> Bob Proulx wrote:
>>> * The mode bits of a symlink are not used.  The original Unix authors
>>>   ignored them and did not provide any way to change them.
>>
>> That's true for Linux, but false for BSD (where the mode bits of a
>> symlink can allow restriction on dereferencing through the symlink).
> 
> What?!  I was not aware of this.  I have been too SysV centric for too
> many years.  And I do not have access to a BSD system in which to
> learn about it.
> 
> It would be informative to myself and I expect others if you could
> post an example of the behavior from a BSD system showing the
> restriction through a symlink's permissions.

Right now, I only had easy access to 64-bit FreeBSD 8.2-RELEASE, and
there, the system call lchmod(2) exists, but 'man 7 symlink' states that
access permissions are ignored.

But I still remember reading about permissions affecting symlinks on at
least one BSD variant (I'm still trying to find where I remember that
from); something like 'w' permissions were required for readlink(2) to
succeed, and 'x' permissions required for open(2) and friends to
successfully follow the symlink.  I'll post back if I can find more
evidence.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #34 received at 10311 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
Cc: 10311 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>,
	Jan Engelhardt <jengelh <at> medozas.de>
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Fri, 16 Dec 2011 13:16:11 -0700

[Message part 1 (text/plain, inline)]

On 12/16/2011 12:04 PM, Eric Blake wrote:
>> It would be informative to myself and I expect others if you could
>> post an example of the behavior from a BSD system showing the
>> restriction through a symlink's permissions.
> 
> But I still remember reading about permissions affecting symlinks on at
> least one BSD variant (I'm still trying to find where I remember that
> from); something like 'w' permissions were required for readlink(2) to
> succeed, and 'x' permissions required for open(2) and friends to
> successfully follow the symlink.  I'll post back if I can find more
> evidence.

NetBSD is the one I was remembering, and it is a per-device mount-option
that controls whether permissions matter (alas, I have no root
permissions on any of the NetBSD systems I currently have access to, in
order to try out the mount option and show an actual transcript of a
permission-enforced failure):

http://www.daemon-systems.org/man/symlink.7.html

     If the filesystem is mounted with the symperm mount(8) option, the sym-
     bolic link file permission bits have the following effects:

     The readlink(2) system call requires read permissions on the symbolic
     link.

     System calls that follow symbolic links will fail without
execute/search
     permissions on all the symbolic links followed.

     The write, sticky, set-user-ID-on-execution and
set-group-ID-on-execution
     symbolic link mode bits have no effect on any system calls (including
     execve(2)).

So it was 'r' and 'x' bits that matter ('w' is still inconsequential,
even with symperm enabled on a device, although lchmod() and
fchmodat(AT_SYMLINK_NOFOLLOW) let you modify all the bits).

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #39 received at 10311-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 10311-done <at> debbugs.gnu.org
Subject: Re: bug#10311: RFE: Give chmod a "-h" option as well
Date: Wed, 20 Mar 2024 19:16:00 +0000

On 16/12/2011 16:29, Jan Engelhardt wrote:
> Hi,
> 
> chown(1) has a -h option by which it affects symlinks directly rather
> than the pointed-to file. The bonus side effect is that the
> pointed-to files don't get changed in any way, which is kinda welcome
> if you attempt to "fix" permissions/ownership in a directory where an
> evil user could create a symlink to e.g. /etc/shadow.
> 
> 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).

Pushed at
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v9.4-162-g07a69fc3b

Marking as done.

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.