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: <200405131649.i4DGn290079309@kac.cnri.dit.ie>
Date: Thu, 13 May 2004 17:49:02 +0100
From: David Malone <dwmalone@...i.dit.ie>
To: bugtraq@...urityfocus.com
Subject: Curious fileutils/coreutils behaviour.


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 root:
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.
---


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ