chown funktioniert nicht?!
roger
- perl
0 Matti Maekitalo0 Roger0 Michael Schröpl0 Roger
hallo!
ich habe ein script geschrieben, welches ein verzeichnis anlegt.
(riesen ding: mkdir($verzeichnis, 0755);)
jetzt soll es (das verzeichnis) aber noch den benutzer wechseln. mit chown dachte ich wär das kein problem, da ja das script sowieso erst mal besitzer des verzeichnisses ist (hat es ja selber angelegt). allerdings passiert hier nix. oder vielmehr: "opperation not permitted".
klasse und nu?
mit system() komm' ich auch nicht weiter. vielleicht nur ne sysntax frage?
::
chown(560,50,$verzeichnis) or die print $!;
oder
system("chown 560.50 $verzeichnis") or die print $!;
thanx°!
use Mosche;
jetzt soll es (das verzeichnis) aber noch den benutzer wechseln. mit chown dachte ich wär das kein problem, da ja das script sowieso erst mal besitzer des verzeichnisses ist (hat es ja selber angelegt). allerdings passiert hier nix. oder vielmehr: "opperation not permitted".
`perldoc -f chown':
"On most systems, you are not allowed to change the ownership of the file unless you're the superuser"
use Tschoe qw(Matti);
use Mosche;
`perldoc -f chown':
"On most systems, you are not allowed to change the ownership of the file unless you're the superuser"
das hab ich schon irgendwie mitbekommen. schmerzlich.
aber wie krieg ich das hin? (habe root-zugang)
-U bringt auch nicht viel, oder?
use Tschoe qw(Matti);
Hi,
"On most systems, you are not allowed to change
the ownership of the file unless you're the
superuser"
das hab ich schon irgendwie mitbekommen. schmerzlich.
im Gegenteil: Wenn jeder Anwender den Owner einer Datei ändern dürfte, dann könnte er
1. das "rm"-Kommando kopieren,
2. für die Kopie das User-S-Bit setzen,
3. den Owner auf "root" setzen und
4. damit nun jede Datei der gesamten Festplatte löschen.
Nicht gut. :-(
aber wie krieg ich das hin? (habe root-zugang)
Das nützt Dir nichts. Dein CGI-Skript müßte "root"-Recht haben. Das aber wäre so ziemlich die schlimmste Sicherheitslücke, die ich mir vorstellen könnte.
Ändere Dein Konzept. Es _darf_ nicht vom owner einer Datei oder eines Verzeichnisses abhängen. Es gibt zahlreiche bessere Lösungen.
Viele Grüße
Michael
Hi,
Ändere Dein Konzept. Es _darf_ nicht vom owner einer Datei oder eines Verzeichnisses abhängen. Es gibt zahlreiche bessere Lösungen.
eine lösung wäre dann meiner meinung nach ein cron-job, der dann die sache erledigt. wäre nicht die schnellste und effektivste, aber mit diesem könnte ich zumindest ein skript als root ausführen.
gibts eventuell noch andere möglichkeiten?
Viele Grüße
roger.
hi roger,
eine lösung wäre dann meiner meinung nach ein
cron-job, der dann die sache erledigt. wäre nicht
die schnellste und effektivste, aber mit diesem
könnte ich zumindest ein skript als root ausführen.
das ändert aber nichts daran, daß dieser cron-Job
einen Befehl als "root" ausführt, der "von außen"
parametrisiert wird. Damit öffnest Du eine Sicher-
heitslücke in Deinem System.
Wieso brauchst Du denn überhaupt einen anderen owner?
Wieso ist Deine Aufgabe nicht über einen angemessenen
Einsatz des Gruppen-Konzeptes von UNiX lösbar?
Viele Grüße
Michael
hi michael,
das ändert aber nichts daran, daß dieser cron-Job
einen Befehl als "root" ausführt, der "von außen"
parametrisiert wird. Damit öffnest Du eine Sicher-
heitslücke in Deinem System.
wieso? der cron wird doch vom system ausgeführt...
"mache mit datei soundso dasunddas"
Wieso brauchst Du denn überhaupt einen anderen owner?
Wieso ist Deine Aufgabe nicht über einen angemessenen
Einsatz des Gruppen-Konzeptes von UNiX lösbar?
nicht das ich wüsste, zumindest fehlen mir hier diesbezüglich noch die kenntnisse. ich kann zb. als ftp owner die rechte für meine verzeichnisse wie ich will vergeben/benutzer ändern. als wwwrun nun mal nicht. (siehe erster thread) ich denke doch dass dies zumindest bei den verzeichnissen gehen müsste, die ich mit der selben gruppe angelegt habe.
vielleicht denke ich auch in die falsche richtung.
sorry.
Viele Grüße
roger
Hi roger,
das ändert aber nichts daran, daß dieser cron-Job
einen Befehl als "root" ausführt, der "von außen"
parametrisiert wird. Damit öffnest Du eine Sicher-
heitslücke in Deinem System.
wieso? der cron wird doch vom system ausgeführt...
"mache mit datei soundso dasunddas"
Ja, aber das, was das Kommando _tun_ soll, wird durch eine externe Eingabe beeinflußt. Das ist nicht anders, als wenn Du eine shell unter root verwenden würdest - die Eingabe in die Shell kommt auch von außen.
Wieso brauchst Du denn überhaupt einen anderen owner?
Wieso ist Deine Aufgabe nicht über einen angemessenen
Einsatz des Gruppen-Konzeptes von UNiX lösbar?
nicht das ich wüsste, zumindest fehlen mir hier
diesbezüglich noch die kenntnisse.
Mach Dir einfach mal klar, was Du überhaupt tun willst.
Streiche die Idee, chown zu verwenden, aus Deinem Gedächtnis.
ich kann zb. als ftp owner die rechte für meine
verzeichnisse wie ich will vergeben/benutzer ändern.
als wwwrun nun mal nicht. (siehe erster thread)
Das kommt darauf an, _welche_ Rechte!
Die Ownership ist nicht _Dein_ Recht - derjenige, dem Du die Datei "unterschieben" willst, müßte damit einverstanden sein.
Dafür gibt es aber keinen Mechanismus - deshalb darf das nur root, der immer Recht hat.
ich denke doch dass dies zumindest bei den
verzeichnissen gehen müsste, die ich mit der selben
gruppe angelegt habe.
Alle Benutzer aus derselben Gruppe dürfen diejenigen Operationen mit dem Objekt ausführen, welche ihnen durch das Setzen der entsprechenden Berechtigungsbits zur Verfügung gestellt wurden. Das Ändern des Owners gehört nicht dazu.
vielleicht denke ich auch in die falsche richtung.
sorry.
Kein Grund für eine Entschuldigung: Ich will Dir ja nur bewußt machen, daß Du in eine andere Richtung denken _sollst_, weil die bisherige Dich in eine Sackgasse geführt hat.
Das UNIX-Berechtigungssystem, gerade mit seinem Gruppenkonzept, kann so viel, daß ich mir eine Aufgabenstellung, welche damit nicht lösbar ist, kaum vorstellen kann.
Vergiß die owner-Idee und beschreibe (notfalls nur Dir selbst, gerne aber auch hier im Forum), _was_ Du eigentlich erreichen willst. Das ist (in dieser Phase Deines Entwurfs) viel wichtiger, als _wie_ Du es erreichen willst. Klebe nicht an Deiner Idee.
Viele Grüße
Michael