Curious fileutils/coreutils behaviour.

[David Malone]

While replacing sendmail on a system using GNU fileutils 4.something
I encountered something that surprised me. I did a "make install" of
our version of mmdf, which does a "cp blah /usr/sbin/sendmail ;
chown mmdf /usr/sbin/sendmail ; chmod u+s /usr/sbin/sendmail"

Now, /usr/sbin/sendmail was a symlink (which I knew), which eventually
resolves to /usr/sbin/sendmail.sendmail. After the install I ended
up with the following:

lrwxrwxrwx 1 mmdf mail 21 Dec 13 22:50 /usr/sbin/sendmail -> /etc/alternatives/mta
-rwsr-xr-x 1 root smmsp 522779 Mar 20 14:53 /usr/sbin/sendmail.sendmail

Note that while the symlink was chowned it was the target of the
symlink that was chmoded. This resulted in a suid root file that
should have been suid mmdf!

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. (Though there seems to be a stat/lstat
bug in coreutils 5.2.1. If you run this as ro
ln -s b a ; touch b ; chown dwmalone a ; chown --dereference dwmalone a
then b ends up owned by root rather than dwmalone).

While this choice of default isn't clearly wrong, I found it
surprising. I had a look to see if this had been discussed before.
All I turned up was the fileutils FAQ entry, included below, which
seems to be at odds with "-h" being the default for chown. This
choice of behaviour still exists in coreutile 5.2.1 as far as I can
see.

David.

---
How do I change the ownership or permissions of a symlink?

The owner, group, and permissions of a symlink are not in any way
significant. Only the value of the symlink is meaningful. Regardless
of that some operating systems will allow you change the owner,
group or mode of a symlink and other operating systems will not.
Do not worry about it as it does not matter in any case.
---

[Michael Wojcik]

> From: David Malone [mailto:dwmalone@cnri.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

[Nicolas Rachinsky]

* David Malone <dwmalone@cnri.dit.ie> [2004-05-13 17:49 +0100]:
> 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. (Though there seems to be a stat/lstat
> bug in coreutils 5.2.1. If you run this as ro
> ln -s b a ; touch b ; chown dwmalone a ; chown --dereference dwmalone a
> then b ends up owned by root rather than dwmalone).
>
> While this choice of default isn't clearly wrong, I found it
> surprising.

This behaviour violates the single unix specification if I read it
correctly. There is explicitly stated that chown should behave like
chown(), which should -- unlike lchown() -- change the file a symlink
points to.

Nicolas

[David Malone]

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

Yes, indeed. As another example, Apache has an option to only follow
symlinks if they belong to the right person.

David.

[Michael Shigorin]

--NDin8bjvE/0mNLFQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 14, 2004 at 07:49:07PM +0100, David Malone wrote:
> > (*)Contrary to the FAQ entry you cited, it is sometimes useful to chang=
e the
> > ownership of a symlink. Since the owner of a symlink can be detected b=
y a
> > program, there can exist programs which depend on it.
> Yes, indeed. As another example, Apache has an option to only
> follow symlinks if they belong to the right person.

OpenWall Linux kernel patch also finds some usage for ownership
of symlinks in +t directories, just in case.

OTOH: I've recently had to fix permissions of a bunch of symlinks
(exactly due to -ow effect); apparently in ALT Linux the default
behaviour of coreutils-5.2.1 is to affect the target though at a
quick skim I can't identify the relevant patch, if any.

--=20
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/

--NDin8bjvE/0mNLFQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFApbsrbsPDprYMm3IRApIuAKC/6QCEvU+SwSp/ZWgbdinLybTlXACfaY1V
LmD//Voeak9beeFdLNJjoig=
=WbEU
-----END PGP SIGNATURE-----

--NDin8bjvE/0mNLFQ--

[Luciano Miguel Ferreira Rocha]

On Fri, May 14, 2004 at 07:49:07PM +0100, David Malone wrote:
> > (*)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.
>
> Yes, indeed. As another example, Apache has an option to only follow
> symlinks if they belong to the right person.

If the target belongs to the right person, not the symlink itself.

Regards,
Luciano Rocha

--
Consciousness: that annoying time between naps.

[Martin]

SymLinksIfOwnerMatch
The server will only follow symbolic links for which the target file
or directory is owned by the same user id as the link.
*Note*: this option gets ignored if set inside a <Location> section.

From http://httpd.apache.org/docs/mod/core.html#options


Luciano Miguel Ferreira Rocha wrote:

>On Fri, May 14, 2004 at 07:49:07PM +0100, David Malone wrote:
>
>
>>>(*)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.
>>>
>>>
>>Yes, indeed. As another example, Apache has an option to only follow
>>symlinks if they belong to the right person.
>>
>>
>
>If the target belongs to the right person, not the symlink itself.
>
>Regards,
>Luciano Rocha
>
>
>