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-prev] [day] [month] [year] [list]

Message-ID: <20040514211335.GA68100@pc5.i.0x5.de>
Date: Fri, 14 May 2004 23:13:35 +0200
From: Nicolas Rachinsky <list@...hinsky.de>
To: David Malone <dwmalone@...i.dit.ie>
Cc: bugtraq@...urityfocus.com
Subject: Re: Curious fileutils/coreutils behaviour.

* David Malone <dwmalone@...i.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 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.

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