nicht angemeldet
Linux, Mehrfach-Owner, Offener und geschlossener FTP-Bereich
Hellihello,
in der HTML-Ag, die ich betreue, habe ich bisher den FTP-Zugang auf den Webspace komplett freigegeben - Nutzername und Passwort stehen auf der Seite im Netz. Da die Domainzuordnung inklusive User und dazugehörgiem Heimatverzeichnis mit Plesk eingerichtet wurde und das auch weiter mit Plesk wartbar bleiben soll, würde ich dies auch gerne erstmal so lassen.
Dennoch sollte es im Heimatverzeichnis /var/www/vhosts/our.domain.tld/httpdocs jetzt einen weiteren User geben, der eben auf bestimmte Dateien (zB. die index.html) alleiniges Zugriffsrecht hat. Über Yast (ist Suse) ließe sich das ja vielleicht einrichten (User/Homeverzeichnis); aber wie geht es, dass das o.g. Verzeichnis einen weiteren Owner ("html-ag-admin") erhält? Der "open-html-ag-user" soll ja weiterhin gewohnten Zugriff haben, also zB. einzelne Schüler auf ihre eingerichteten Unterverzeichnisse.
Dank und Gruß,
-
hallo,
[..] aber wie geht es [...]
Eventuell sollten wir mal, um alle deine Linux-Probleme und -fragen durchzukaspern, ein offline-Treffen vereinbaren, meine Telefonnummer kenst du ja noch ;-)
Grüße aus Berlin
Christoph S.
-
Hellihello Christoph,
Eventuell sollten wir mal, um alle deine Linux-Probleme und -fragen durchzukaspern, ein offline-Treffen vereinbaren, meine Telefonnummer kenst du ja noch ;-)
Ja, danke fürs Angebot. In dem jetzigen Fall könnte mir vielleicht http://de.wikipedia.org/wiki/Access_Control_List weiterhelfen. Dumme Frage: muss man "das" installieren? Ist das überhaupt was für Suse 9.3 und VServer?
Dank und Gruß,
-
Hellihello
│acl - Commands for Manipulating POSIX Access Control Lists │
│Version: 2.2.30-3 Installed: 2.2.30-3 Size: 128.7 kB Media No.: 1 │
│License: GPL, Other License(s), see package │
│Package Group: System/Filesystems │
│Provides: acl = 2.2.30-3 │
│Authors: Andreas Gruenbacher , SGIsagt mir das YAST. Es sollte wohl installiert sein.
Weil das laut http://www.linuxquestions.org/questions/mandriva-30/setfacl-test-operation-not-supported-266804/ ein Problem lösen kann, was ich habe:
h1028341:/robert # setfacl -m user:robert:rwx test.test
setfacl: test.test: Operation not supportedDank und Gruß,
-
Hallo Frank,
h1028341:/robert # setfacl -m user:robert:rwx test.test
setfacl: test.test: Operation not supportedDu musst das Dateisystem mit acl-Unterstützung mounten, d.h.:
mount /dateisystem -o remount,acl
Wenn Du willst, dass das beim nächsten Booten hält, schreibe das in das Optionsfeld der /etc/fstab zu dem Dateisystem hinzu.
Im _Normfalfall_ sollten die meisten vorkompilierten Kernel ACL-Unterstützung bieten, wenn dies wider Erwarten nicht der Fall sein sollte, müsstest Du wohl oder übel Deinen Kernel mit ACL-Unterstützung für das von Dir gewählte Dateisystem neu kompilieren.
Viele Grüße,
Christian-
Hellihello Christian,
merci.
h1028341:/robert # setfacl -m user:robert:rwx test.test
setfacl: test.test: Operation not supportedDu musst das Dateisystem mit acl-Unterstützung mounten, d.h.:
mount /dateisystem -o remount,acl
Was heißt denn "remount,acl"? Als Dateisystem wäre dann "reiserfs" (s.u.) einzutragen, oder?
Es ist doch ein virtuelle Server bei Strato, mittels virtuozzo glaub ich. Frag ich nach "mount, kommt:
h1028341:~ # mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)kann ich mit o.g. was "kaputt" machen am laufenden Betrieb?
Wenn Du willst, dass das beim nächsten Booten hält, schreibe das in das Optionsfeld der /etc/fstab zu dem Dateisystem hinzu.
Das wäre dann in dem Fall ein Reboot über die Admin-Config. Von allein booted der sich glaub ich nicht neu.
Im _Normfalfall_ sollten die meisten vorkompilierten Kernel ACL-Unterstützung bieten, wenn dies wider Erwarten nicht der Fall sein sollte, müsstest Du wohl oder übel Deinen Kernel mit ACL-Unterstützung für das von Dir gewählte Dateisystem neu kompilieren.
Beim VServer geht das bestimmt nicht.
Dank und Gruß,
-
Hallo Frank,
h1028341:/robert # setfacl -m user:robert:rwx test.test
setfacl: test.test: Operation not supportedDu musst das Dateisystem mit acl-Unterstützung mounten, d.h.:
mount /dateisystem -o remount,acl
Was heißt denn "remount,acl"?
Das heißt, dass das, was unter /dateisystem eingehängt ist, "neu gemountet" werden soll, mit anderen Optionen.
Beispiel:
mount / -o remount,ro
Das würde das Dateisystem, das in / gemountet ist, readonly neu mounten (funktioniert allerdings nur, wenn niemand mehr etwas zum Schreiben offen hat).
Genauso würde
monut / -o remount,acl
das Dateisystem / mit der Option acl neu gemountet werden. Im Gegensatz zu ro ist das aber ein viel geringerer Eingriff, der eigentlich immer funktioniert.
Als Dateisystem wäre dann "reiserfs" (s.u.) einzutragen, oder?
Nein, mit /dateisystem meinte ich, dass Du ja unter Umständen mehrere Partitionen an verschiedene Stellen gemountet hast, z.B. /, /home, /srv oder sowas. Aber wie man aus Deinem Posting erkennt:
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
Hast Du nur ein Dateisystem nach / gemountet, d.h. bei Dir sollte funktionieren:
mount / -o remount,acl
kann ich mit o.g. was "kaputt" machen am laufenden Betrieb?
Mit dem Mount-Befehl und acl als Option? Nein. Entweder der funktioniert und Du hast ACLs (d.h. setfacl funktioniert hinterher) oder er funktioniert nicht und Du müsstest den Kernel neu kompilieren.
Das Problem: Der Befehl mount ist temporär, d.h. beim nächsten Reboot ist er weg. Damit das dauerhaft bleibt:
In Deiner /etc/fstab dürfte irgendwo eine Zeile zu finden sein, die ungefähr so aussieht (auf Grund Deiner Angaben habe ich versucht, das möglichst gut zu interpolieren, allerdings kann es durchaus noch kleinere Abweichungen geben):
/dev/vzfs / reiserfs usrquota,grpquota 0 1
Diese Zeile müsstest Du nun ändern in:
/dev/vzfs / reiserfs usrquota,grpquota,acl 0 1
Damit bleibt die ACL-Option auch beim nächsten Booten erhalten.
Das wäre dann in dem Fall ein Reboot über die Admin-Config. Von allein booted der sich glaub ich nicht neu.
Oder wenn der Server, der die VServer hostet, mal abschmieren sollte und der Provider den neu starten muss. Das dürfte zwar extrem selten sein, kann aber schonmal vorkommen. Wäre doch ziemlich blöd, wenn dann die ACLs nicht mehr gingen und Du weil das dann schon viel zu lange her ist nicht mehr wüßtest, was denn nun am System kaputt sei. ;-) Daher sind solche Änderungen grundsätzlich *immer* korrekt nachzutragen, damit spart man sich _enorm_ viele Probleme.
Im _Normfalfall_ sollten die meisten vorkompilierten Kernel ACL-Unterstützung bieten, wenn dies wider Erwarten nicht der Fall sein sollte, müsstest Du wohl oder übel Deinen Kernel mit ACL-Unterstützung für das von Dir gewählte Dateisystem neu kompilieren.
Beim VServer geht das bestimmt nicht.
Dann musst Du hoffen, dass der Kernel das schon kann. Wobei ich schon sagte, dass das in der Regel der Fall ist, es würde mich stark wundern, wenn nicht.
Viele Grüße,
Christian-
Hellihello Christian,
Genauso würde
monut / -o remount,acl
das Dateisystem / mit der Option acl neu gemountet werden. Im Gegensatz zu ro ist das aber ein viel geringerer Eingriff, der eigentlich immer funktioniert.
Als Dateisystem wäre dann "reiserfs" (s.u.) einzutragen, oder?
Nein, mit /dateisystem meinte ich, dass Du ja unter Umständen mehrere Partitionen an verschiedene Stellen gemountet hast, z.B. /, /home, /srv oder sowas. Aber wie man aus Deinem Posting erkennt:
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
Hast Du nur ein Dateisystem nach / gemountet, d.h. bei Dir sollte funktionieren:
mount / -o remount,acl
h1028341:~ # mount / -o remount,acl
mount: / not mounted already, or bad option"bad option", nun ja.
Mit dem Mount-Befehl und acl als Option? Nein. Entweder der funktioniert und Du hast ACLs (d.h. setfacl funktioniert hinterher) oder er funktioniert nicht und Du müsstest den Kernel neu kompilieren.
ansehen kann man dass dem Kernel nicht, und dass laut YAST acl "installiert" ist, sagt och nischt, oder?
Das Problem: Der Befehl mount ist temporär, d.h. beim nächsten Reboot ist er weg. Damit das dauerhaft bleibt:
In Deiner /etc/fstab dürfte irgendwo eine Zeile zu finden sein, die ungefähr so aussieht (auf Grund Deiner Angaben habe ich versucht, das möglichst gut zu interpolieren, allerdings kann es durchaus noch kleinere Abweichungen geben):
/dev/vzfs / reiserfs usrquota,grpquota 0 1
Diese Zeile müsstest Du nun ändern in:
/dev/vzfs / reiserfs usrquota,grpquota,acl 0 1
Da steht:
h1028341:~ # cat /etc/fstab
proc /proc proc defaults 0 0
none /dev/pts devpts rw 0 0aber wenn das remount schon nicht klappt, bringt das wohl auch nicht viel.
Im _Normfalfall_ sollten die meisten vorkompilierten Kernel ACL-Unterstützung bieten, wenn dies wider Erwarten nicht der Fall sein sollte, müsstest Du wohl oder übel Deinen Kernel mit ACL-Unterstützung für das von Dir gewählte Dateisystem neu kompilieren.
Beim VServer geht das bestimmt nicht.
Dann musst Du hoffen, dass der Kernel das schon kann. Wobei ich schon sagte, dass das in der Regel der Fall ist, es würde mich stark wundern, wenn nicht.
Nun, ich habe jetzt schon howtos gefunden, wo einer gentoo auf einen 1&1-vserver installiert bekommen hat. Zu gehen scheint vieles, fragt sich in dem Zusammenhang, ob ich da nicht vielleicht einen anderen Weg gehen sollte. Dachte, ACL wäre eine feine Sache, um im allgemein zugänglichen Verzeichnis ein paar zentrale Dateien und Verzeichnisse einem Admin-User zugänglich zu machen. Müsste ich vielleicht doch das httpdocs eine Gruppe als owner geben. Hoffte halt eine Lösung zu finden, die die gePLESKten Konfigurationen bestehen lassen könnte.
Dank und Gruß,
-
Hellihello
sehe ich es richtig, dass ich auf einen Unterordner nur dann zugreifen kann, wenn mir der übergeordnete Ordner auch zumindest ein Leserecht einräumt (rwxr-xr-x, in dem Fall wäre "ich" weder Owner noch Group-Mitglied). Wenn dann in dem Unterverzeichnis aber eine Datei oder ein Verzeichnis steckt, dass mir gehört, kann ich dann rwx-en nach belieben, auch wenn der Überordner das eigentlich nicht vorsieht. Wenn ich aber keine Leserechte als "rest der Welt" hätte (rwxrwx---), käme ich in den Ornder garnicht "rein", also auch nicht an "mein" Verzeichnis ran?
Die /var/www/vhosts/example.coms haben 755er Rechte, aber die httpdocs darin dann 750.
zB:
drwxr-x--- 5 wvs-berlin psaserv 4096 Mar 9 2007 httpdocs
oder manche auch 770 (komisch, dass sich das unterscheidet).
drwxrwx--- 64 html-ag psaserv 4096 Jan 24 22:39 httpdocs
Die Subdomains aber haben 755.
drwxr-xr-x 13 root psaserv 4096 Dec 7 14:07 subdomains
Gibt es einen Grund, das Verzeichnis httpdocs nicht auf 755 zu chmod-en? Sicherheitstechnisch zB.?
Dank und Gruß,
-
Hallo Frank,
sehe ich es richtig, dass ich auf einen Unterordner nur dann zugreifen kann, wenn mir der übergeordnete Ordner auch zumindest ein Leserecht einräumt (rwxr-xr-x, in dem Fall wäre "ich" weder Owner noch Group-Mitglied). Wenn dann in dem Unterverzeichnis aber eine Datei oder ein Verzeichnis steckt, dass mir gehört, kann ich dann rwx-en nach belieben, auch wenn der Überordner das eigentlich nicht vorsieht. Wenn ich aber keine Leserechte als "rest der Welt" hätte (rwxrwx---), käme ich in den Ornder garnicht "rein", also auch nicht an "mein" Verzeichnis ran?
Ich hatte gerade ein längeres Posting verfasst, das Verzeichnisrechte unter UNIX näher erklärt. Und dann ist mir der Browser abgekackt, als ich so gut wie fertig war. Da ich morgen früh aufstehen muss, antworte ich mal kurz und knapp: Im Prinzip und für Deine Zwecke hast Du es richtig verstanden, es gibt noch ein paar Feinheiten, die ich Dir gerne erklären würde, an welchem Recht das nun GENAU hängt, das reiche ich morgen nach.
Die /var/www/vhosts/example.coms haben 755er Rechte, aber die httpdocs darin dann 750.
zB:
drwxr-x--- 5 wvs-berlin psaserv 4096 Mar 9 2007 httpdocs
oder manche auch 770 (komisch, dass sich das unterscheidet).
drwxrwx--- 64 html-ag psaserv 4096 Jan 24 22:39 httpdocs
Die Subdomains aber haben 755.
drwxr-xr-x 13 root psaserv 4096 Dec 7 14:07 subdomains
Gibt es einen Grund, das Verzeichnis httpdocs nicht auf 755 zu chmod-en? Sicherheitstechnisch zB.?
Weiß nicht. Wenn /var/www/vhosts/example.com 755 ist und /var/www/vhosts/example.com/httpdocs auch 755 ist (und ich gehe auch mal für das gleiche bei /var, /var/www und /var/www/vhosts aus), dann kann halt wirklich JEDER den Inhalt von /var/www/vhosts/example.com/httpdocs lesen, sonst nur der User wvs-berlin oder die Gruppe psaserv. Hängt wohl stark davon ab, was in dem Verzeichnis httpdocs drin ist und vor wem Du was abschotten willst, ob das sicherheitsrelevant ist, oder nicht. Etwas mehr Hintergrundinfos wären nicht schlecht.
Viele Grüße,
Christian-
Hellihello Christian,
Ich hatte gerade ein längeres Posting verfasst, das Verzeichnisrechte unter UNIX näher erklärt. Und dann ist mir der Browser abgekackt, als ich so gut wie fertig war. Da ich morgen früh aufstehen muss, antworte ich mal kurz und knapp: Im Prinzip und für Deine Zwecke hast Du es richtig verstanden, es gibt noch ein paar Feinheiten, die ich Dir gerne erklären würde, an welchem Recht das nun GENAU hängt, das reiche ich morgen nach.
Damned. Christoph hatte doch letzlich eins verloren, aber seitdem gibts ja die Auszeichnung der Vorschau.
Die /var/www/vhosts/example.coms haben 755er Rechte, aber die httpdocs darin dann 750.
zB:
drwxr-x--- 5 wvs-berlin psaserv 4096 Mar 9 2007 httpdocs
oder manche auch 770 (komisch, dass sich das unterscheidet).
drwxrwx--- 64 html-ag psaserv 4096 Jan 24 22:39 httpdocs
Die Subdomains aber haben 755.
drwxr-xr-x 13 root psaserv 4096 Dec 7 14:07 subdomains
Gibt es einen Grund, das Verzeichnis httpdocs nicht auf 755 zu chmod-en? Sicherheitstechnisch zB.?
Weiß nicht. Wenn /var/www/vhosts/example.com 755 ist und /var/www/vhosts/example.com/httpdocs auch 755 ist (und ich gehe auch mal für das gleiche bei /var, /var/www und /var/www/vhosts aus), dann kann halt wirklich JEDER den Inhalt von /var/www/vhosts/example.com/httpdocs lesen, sonst nur der User wvs-berlin oder die Gruppe psaserv. Hängt wohl stark davon ab, was in dem Verzeichnis httpdocs drin ist und vor wem Du was abschotten willst, ob das sicherheitsrelevant ist, oder nicht. Etwas mehr Hintergrundinfos wären nicht schlecht.
Nun ja, zur Zeit kann da im Grunde sowieso jeder rein in das Verzeichnis, der der Lesens mächtig ist, und auf der Seite der AG das Howto zum Serverzugang findet. Deshalb wollte ich ja jetzt es so einrichten, dass das httpdocs im Grunde frei zugänglich bleibt (entweder allen, die die Seite lesen, oder, wenn das mal missbraucht wird, jedem in der Schule, der möchte). Aber bestimmte Bereiche würde ich gerne nur den Admins zugänglich machen. Das wäre die index.php und nach Belieben weitere Verzeichnisse/Dateien.
Meine erste Idee war, also die bisherige Struktur zu erhalten und darin Ausnahmen zu schaffen. Andere Ansatz wäre, die index.php "einzfrieren", sie den Besitzer in root zu änderen, und geschützte Bereiche via Plesk in eine Subdomain auszulagern, und diese dann auch via Plesk mit einem anderen FTP-User zu versehen. ACL hätte ich geschmeidiger gefunden. Und beim Sinnieren über andere Möglichkeiten war ich jetzt darauf gestoßen, dass mir die Feinheiten des Rechtesystems scheinbar noch nicht ganz klar sind. Zumindest kan nich aber "httpdocs" mit "html-ag" als owner und "psaserv" als group nicht als Heimatverzeichnis für einen eigenen per YAST oder adduser erstellten "admin-html-ag"-User definieren, weil der als "Rest-der-Welt" da garnicht reinkommt.
Dank und Gruß,
-
-
-
Hallo Frank,
h1028341:~ # mount / -o remount,acl
mount: / not mounted already, or bad option"bad option", nun ja.
Doof das. Hätte ich jetzt nicht erwartet...
Mit dem Mount-Befehl und acl als Option? Nein. Entweder der funktioniert und Du hast ACLs (d.h. setfacl funktioniert hinterher) oder er funktioniert nicht und Du müsstest den Kernel neu kompilieren.
ansehen kann man dass dem Kernel nicht, und dass laut YAST acl "installiert" ist, sagt och nischt, oder?
Das acl-Paket, das Du über YAST installieren kannst, enthält im Prinzip nur die Tools mit denen Du ACLs setzen kannst, d.h. durch die Installation dieses Pakets gibt es überhaupt die Befehle 'getfacl' und 'setfacl' (und noch ein paar andere Dinge mehr) - das ändert aber leider nichts daran, dass diese Tools nur eine Schnittstelle zum Kernel sind und der das auchkönnen muss. Ich kann echt nicht nachvollziehen, dass das Feature in einem vorkompilierten Kernel nicht vorhanden ist, zumal man es ja sowieso erst separat aktivieren muss per Mount-Option, wenn man es nutzen will, d.h. es keinen Schaden anrichtet, wenn man es nicht braucht...
[/etc/fstab] Da steht:
h1028341:~ # cat /etc/fstab
proc /proc proc defaults 0 0
none /dev/pts devpts rw 0 0Oh, das ist SEHR seltsam. Ich kenne SuSE nicht mehr wirklich (letzte SuSE-Version mit der ich noch was gemacht habe war 6.1 oder so), aber der Mangel des Eintrages lässt darauf schließen, dass die Optionen für das Root-Dateisystem bei SuSE woanders eingestellt werden (SuSE hat's wohl immer noch nicht gelernt, sich an sinnvolle Konventionen zu halten...).
aber wenn das remount schon nicht klappt, bringt das wohl auch nicht viel.
Ja.
Nun, ich habe jetzt schon howtos gefunden, wo einer gentoo auf einen 1&1-vserver installiert bekommen hat.
Gentoo selbst stellt relativ wenig Anforderungen an Kernel-Optionen an sich, und die, die es stellt, dürften in jedem normalen Distributionskernel auch aktiviert sein. Sprich: Ich _vermute_ stark, der hat den vorkompilierten SuSE-Kernel genommen und darauf aufbauend Gentoo installiert. Das würde Dir natürlich auch nichts nützen, denn ein Gentoo, das unter dem gleichen Kernel läuft, wird die gleichen Probleme haben, wie Dein SuSE...
Hoffte halt eine Lösung zu finden, die die gePLESKten Konfigurationen bestehen lassen könnte.
Uuuuuuuh. PLESK... Von solchen Tools lasse ich persönlich die Finger, denn wenn man etwas anders konfiguriert, als in den Tools vorgesehen, dann jagen die einem die Systemkonfiguration um die Ohren. Aber gut, ich will Dir hier nichts ausreden, was nicht DIREKT mit Deinem Problem zu tun hat. ;-)
Viele Grüße,
Christian-
Hellihello Christian,
Hallo Frank,
übrigens entweder "frankx" oder Robert.
[/etc/fstab] Da steht:
h1028341:~ # cat /etc/fstab
proc /proc proc defaults 0 0
none /dev/pts devpts rw 0 0Oh, das ist SEHR seltsam. Ich kenne SuSE nicht mehr wirklich (letzte SuSE-Version mit der ich noch was gemacht habe war 6.1 oder so), aber der Mangel des Eintrages lässt darauf schließen, dass die Optionen für das Root-Dateisystem bei SuSE woanders eingestellt werden (SuSE hat's wohl immer noch nicht gelernt, sich an sinnvolle Konventionen zu halten...).
Oha, ich dachte Suse wäre PC.
Hoffte halt eine Lösung zu finden, die die gePLESKten Konfigurationen bestehen lassen könnte.
Uuuuuuuh. PLESK... Von solchen Tools lasse ich persönlich die Finger, denn wenn man etwas anders konfiguriert, als in den Tools vorgesehen, dann jagen die einem die Systemkonfiguration um die Ohren. Aber gut, ich will Dir hier nichts ausreden, was nicht DIREKT mit Deinem Problem zu tun hat. ;-)
Nun ja, Strato bietet das System mit Plesk an, ohne udn mit Debian 3.1.. Ich hatte mich für Plesk entschieden, weil ich mal schauen wollte, was man damit so machen kann bzw. wie das den Server so einrichtet. Es wird dadurch ggf. vertrackter, wenn man die Pleskheiten nicht kennt, aber ich glaube nach wie vor, dass die Chance für Sicherheitslücken aus Unkenntnis so verringert wird. Ausserdem kann nun ein 11-Klässler mit Plesk die Datenbank administrieren und das Ftp-Passwort ändern und durch Plesk kann man in dem Bereich dann erstmal nix wirklich zerschießen.
Alles andere muss man natürlich dann quasi um Plesk rumbauen. Deshalb scheue ich mich auch erstmal (aus Unkenntnis, wie Plesk das finden würde), dem Ordner "httpdocs" einen neuen Owner (eine Gruppe als Owner) zu verpassen. Mit ACL wäre ihm ja nur ein weiterer User beigstellt worden, was Plesk vermutlich garnicht mitbekommen würde. Alles weitere im anderen posting zu den Rechten.
Dank und Gruß,
-
-
-
-
-
-
-
-