bugtraq - RE: Curious fileutils/coreutils behaviour.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <75C025AE395F374B81F6416B1D4BDEFB01C3BE3C@mtv-corpmail.microfocus.com>
Date: Fri, 14 May 2004 11:19:55 -0700
From: Michael Wojcik <Michael.Wojcik@...rofocus.com>
To: bugtraq@...urityfocus.com
Cc: David Malone <dwmalone@...i.dit.ie>
Subject: RE: Curious fileutils/coreutils behaviour.

> From: David Malone [mailto:dwmalone@...i.dit.ie] 
> Sent: Thursday, May 13, 2004 12:49 PM
> 
> Solaris, AIX, and FreeBSD all seem to have less suprising behaviour
> for chown and chmod and provide a "-h" flag for chowning a symlink
> rather than its target. Fileutils also has a "-h" flag, but it is
> the default for chown, so you need to say "--dereference" to get
> it to operate on the target.
> 
> While this choice of default isn't clearly wrong...

It's pretty clear to me that it's wrong.  It's inconsistent (with the other
utilities) and counterintuitive, which is a major security risk for a
security-sensitive utility.  Changing ownership of a symlink is rarely
useful,(*) so it makes the less-desirable behavior the default.  It operates
differently from other implementations of the chown command, and requires a
nonstandard and implausible flag to force the de facto standard behavior.
That's three strikes against it; it's out.

Of course, changing the default behavior could have adverse effects on shell
scripts and slow learners, so simply correcting it is likely to cause some
grief.  IMO it's worth it in a case like this.

(*)Contrary to the FAQ entry you cited, it is sometimes useful to change the
ownership of a symlink.  Since the owner of a symlink can be detected by a
program, there can exist programs which depend on it.  Consider a script
which uses "find -user x" for some purpose, for example, or the behavior of
directories with the sticky bit set.  Also, there was recently a discussion
of a real-world case on comp.unix.aix where the use of the -h flag behavior
(change link rather than target) would have avoided unfortunate
consequences.  The text of the FAQ entry is a classic case of failing to
consider all the consequences of an action and attending only to the most
obvious ones - a common security error.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus