Re: chown / chgrp als normaler user
Andreas Loesch wrote:
Am Mittwoch, 28. Juli 2004 11:40 schrieb Kyek, Andreas, VF-DE:
Hier ein Beispiel (teilweise als root natürlich, weil ansonsten der chmod nicht geht!)
Kurz: you have a problem!
Ich hatte auch eingentlich ein anderes Verhalten erwartet (und kenne das von unseren "richtigen" Unix Maschinen hier auch anders.) Ich war selber überrascht, das sowohl ein chown als auch ein chgrp das S-Bit unangetastet lässt!
Hier (SuSE 9.0, Kernel 2.6.7):
relativ unwichtig, die Version der coreutils ist wichtiger
Tja, die Version der SuSE 9.0 (5.0-90). Und mittels "rpm --verify" überprüft.
--- cut here --- linux:~ # chown akyek rm linux:~ # ls -al rm -rwsr-xr-x 1 akyek root 21 Jul 28 11:23 rm
autsch
hier Debian(testing/unstable) Linux einstein 2.6.7-1-686 #1 Thu Jul 8 05:36:53 EDT 2004 i686 GNU/Linux
einstein:/tmp/blubb# chown --version chown (coreutils) 5.2.1 Geschrieben von David MacKenzie und Jim Meyering.
[...] Die ist bei der 9.1er auch dabei. Ich habe die installiert (geht problemlos auf der 9.0) und siehe da: Das Phänomen ist weg und die Kiste verhält sich so, wie ich dachte. Gegentest: 5.0 wieder installiert und... S-Bit bleibt stehen. Scheint zwischen v5.0 und v5.2 geändert worden zu sein. Wieder was gelernt. Andreas
Am Donnerstag, 29. Juli 2004 07:37 schrieb Kyek, Andreas, VF-DE:
Andreas Loesch wrote:
einstein:/tmp/blubb# chown --version chown (coreutils) 5.2.1 Geschrieben von David MacKenzie und Jim Meyering.
Die ist bei der 9.1er auch dabei. Ich habe die installiert (geht problemlos auf der 9.0) und siehe da: Das Phänomen ist weg und die Kiste verhält sich so, wie ich dachte.
käme jetzt darauf an, ob das bei der 5.er gewolltes Verhalten ist (info coreutils chown) oder ob da ein Bugreport an SuSE fällig ist.
Gegentest: 5.0 wieder installiert und... S-Bit bleibt stehen.
Scheint zwischen v5.0 und v5.2 geändert worden zu sein.
müsste ja in den Changelogs stehen. gruss Andreas
Andreas Loesch wrote:
[...] müsste ja in den Changelogs stehen.
* Major changes in release 5.0.1 (2003-07-15): [...] - chown no longer tries to preserve set-user-ID and set-group-ID bits; on some systems, the chown syscall resets those bits, and previous versions of the chown command would call chmod to restore the original, pre-chown(2) settings, but that behavior is problematic. 1) There was a window whereby a malicious user, M, could subvert a chown command run by some other user and operating on files in a directory where M has write access. 2) Before (and even now, on systems with chown(2) that doesn't reset those bits), an unwary admin. could use chown unwittingly to create e.g., a set-user-ID root copy of /bin/sh. CU, Th.
participants (3)
-
Andreas Loesch -
Kyek, Andreas, VF-DE -
Thomas Hertweck