Zugriffsrechte-Frage (Verzeichnis / Dateien)

[testit]

Hallo,

ich brüte derzeit über folgendem Problem:


In einem Verzeichnis /home/ftp, gesetzt auf 770, das dem Owner ROOT und der Gruppe WWW gehört, liegt eine Datei test.php, die dem Owner USER gehört.

Bis eben bin ich davon ausgegangen, dass spezielle Datei-Eigentümereigenschaften und -zugriffsrechte (hier: test.php gehört Owner USER) stets die übergeordneten Rechte durchbrechen (hier: die von /home/ftp).

Obwohl die Datei test.php in /home/ftp Owner USER gehört und auf 777 gesetzt ist, kann USER an dieser Datei nichts ändern, wenn das übergeordnete Verzeichnis /home/ftp Owner Root und Gruppe www gehört und auf 770 gesetzt ist.

Und wenn ich will, das USER test.php in /home/ftp bearbeiten kann, muss ich /home/ftp auf 777 setzen, womit er dann aber auch alle anderen Dateien in /home/ftp manipulieren kann, auch wenn ich deren Rechte anders setze und er nicht Eigentümer dieser Dateien ist und auch keiner entsprechenden Gruppe angehört.

Offenbar gehen die Einstellungen von /home/ftp stets vor, sehe ich das richtig?

Danke und Gruss
testit

 

[s-tlk]

was ist wenn du es auf 775 setzt?

 

[rosa]

In einem Verzeichnis /home/ftp, gesetzt auf 770, das dem Owner ROOT und der Gruppe WWW gehört, liegt eine Datei test.php, die dem Owner USER gehört.

Bis eben bin ich davon ausgegangen, dass spezielle Datei-Eigentümereigenschaften und -zugriffsrechte (hier: test.php gehört Owner USER) stets die übergeordneten Rechte durchbrechen (hier: die von /home/ftp).

Natürlich gehört die Datei USER, nur wenn dieser nicht in der Gruppe WWW ist, kann USER das Verzeichnis /home/ftp nicht "betretten" da hier das Execut Bit fehlt.
/home/ftp muss also mindestens 001 haben, soll USER noch lesen können, also sehen was in /home/ftp liegt fehlt noch das Read Bit, dann also 005 (1+4).

Obwohl die Datei test.php in /home/ftp Owner USER gehört und auf 777 gesetzt ist, kann USER an dieser Datei nichts ändern, wenn das übergeordnete Verzeichnis /home/ftp Owner Root und Gruppe www gehört und auf 770 gesetzt ist.

Warum 777, soll deine PHP Datei Ausführbar sein? Sonst würde für lesen und schreiben jeweils 6 (2 + 4 [Lesen/Schreiben]) reichen. Nur was nützt dem USER das wenn er das Verzeichnis gar nicht betretten kann?!

Und wenn ich will, das USER test.php in /home/ftp bearbeiten kann, muss ich /home/ftp auf 777 setzen,

Nein, 005 sollte reichen. Damit er ins Verzeichnis wie oben geschrieben kommt.

womit er dann aber auch alle anderen Dateien in /home/ftp manipulieren kann, auch wenn ich deren Rechte anders setze und er nicht Eigentümer dieser Dateien ist und auch keiner entsprechenden Gruppe angehört.

Ja klar, weil 7 alles ist (lesen,schreiben,ausführen) somit darf er in dem Verzeichnis selbstverständlich schreiben.

Fazit: Du solltest Dich mal genauer mit den UNIX Rechten auseinandersetzen

Gruß paefchen

Edit:
Im FreeBSD Handbuch steht was dazu: http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/permissions.html
und die Man Page kann man sich auch mal anschauen: http://www.freebsd.org/cgi/man.cgi?query=chmod

 

[testit]

Natürlich gehört die Datei USER, nur wenn dieser nicht in der Gruppe WWW ist, kann USER das Verzeichnis /home/ftp nicht "betretten" da hier das Execut Bit fehlt.
/home/ftp muss also mindestens 001 haben, soll USER noch lesen können, also sehen was in /home/ftp liegt fehlt noch das Read Bit, dann also 005 (1+4).



Warum 777, soll deine PHP Datei Ausführbar sein? Sonst würde für lesen und schreiben jeweils 6 (2 + 4 [Lesen/Schreiben]) reichen. Nur was nützt dem USER das wenn er das Verzeichnis gar nicht betretten kann?!



Nein, 005 sollte reichen. Damit er ins Verzeichnis wie oben geschrieben kommt.



Ja klar, weil 7 alles ist (lesen,schreiben,ausführen) somit darf er in dem Verzeichnis selbstverständlich schreiben.

Fazit: Du solltest Dich mal genauer mit den UNIX Rechten auseinandersetzen

Gruß paefchen

Edit:
Im FreeBSD Handbuch steht was dazu: http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/permissions.html
und die Man Page kann man sich auch mal anschauen: http://www.freebsd.org/cgi/man.cgi?query=chmod

Hi,

ich denke, dass ich mich schon ziemlich ausgiebig mit dem Zugriffsrechtesystem unter Unix beschäftigt habe. Das vorliegende Problem ist auch vorher nie bei mir aufgetaucht und erst jetzt deutlich geworden, weil ich einen FTP-Account für einen User angelegt habe, der auf eine ganz bestimmte Datei in seinem FTP-Zielverzeichnis keinen Zugriff haben soll (ein symbol. Link).

Genau DAS funktioniert wider Erwarten nicht so einfach. Der Witz ist, dass es völlig egal ist, ob /home/ftp auf 775, 005 gesetzt ist oder nicht. Sobald /home/ftp auf 775 steht, hat USER zwar die Möglichkeit unter /home/ftp Daten zu lesen, aber er kann keine dorthin transferieren, weil er als USER weder Eigentümer noch Gruppenangehöriger von /home/ftp ist. Erst, wenn man /home/ftp so chmodded, dass "Others" auf rwx steht, hat er auch das Recht, unter /home/ftp nicht nur zu lesen, sondern auch zu schreiben.

Aber dann kann er erstaunlicherweise auch den o.a. dort befindlichen symbolischen Link löschen oder dessen Namen ändern, obwohl der symbolische Link root mit Gruppe www gehört, also USER ebenfalls eigentlich den symbolischen Link nicht ändern können dürfte, da er weder Eigentümer des symbolischen Links ist, noch der betreffenden Gruppe angehört.

Aktuelles Fazit scheint daher zu sein, dass die Eigentümer- und Gruppenzugehörigkeitseigenschaften eines Verzeichnisses nicht von den Eigentümer/Gruppeneigenschaften der in diesem Verzeichnis befindlichen Dateien "durchbrochen" werden können.

ODER ProFTPd würde die Zugriffsrechte nicht korrekt umsetzen und o.a. Problem verursachen, was ich aber nicht glaube, da dies sicherlich schon andere bemerkt hätten.

Gruss
testit

 

[rosa]

ich denke, dass ich mich schon ziemlich ausgiebig mit dem Zugriffsrechtesystem unter Unix beschäftigt habe. Das vorliegende Problem ist auch vorher nie bei mir aufgetaucht und erst jetzt deutlich geworden, weil ich einen FTP-Account für einen User angelegt habe, der auf eine ganz bestimmte Datei in seinem FTP-Zielverzeichnis keinen Zugriff haben soll (ein symbol. Link).

Genau DAS funktioniert wider Erwarten nicht so einfach. Der Witz ist, dass es völlig egal ist, ob /home/ftp auf 775, 005 gesetzt ist oder nicht. Sobald /home/ftp auf 775 steht, hat USER zwar die Möglichkeit unter /home/ftp Daten zu lesen, aber er kann keine dorthin transferieren, weil er als USER weder Eigentümer noch Gruppenangehöriger von /home/ftp ist. Erst, wenn man /home/ftp so chmodded, dass "Others" auf rwx steht, hat er auch das Recht, unter /home/ftp nicht nur zu lesen, sondern auch zu schreiben.

Und was wundert dich daran? Er ist nicht Eigentümmer noch Gruppenzugehöriger also fält er unter "Andere". Hat Andere aber nur lese Rechte kann er natürlich auch nur lsen und nicht schreiben.

Aber dann kann er erstaunlicherweise auch den o.a. dort befindlichen symbolischen Link löschen oder dessen Namen ändern, obwohl der symbolische Link root mit Gruppe www gehört, also USER ebenfalls eigentlich den symbolischen Link nicht ändern können dürfte, da er weder Eigentümer des symbolischen Links ist, noch der betreffenden Gruppe angehört.

kann es sein das /home/ftp vom USER das $HOME ist? weil dann darf er natürlich alles.

 

[testit]

Und was wundert dich daran? Er ist nicht Eigentümmer noch Gruppenzugehöriger also fält er unter "Andere". Hat Andere aber nur lese Rechte kann er natürlich auch nur lsen und nicht schreiben.



kann es sein das /home/ftp vom USER das $HOME ist? weil dann darf er natürlich alles.

Mir ist nicht klar, wie Du darauf kommst, dass er alles in /home/ftp darf, selbst, wenn dieses Verzeichnis sein $HOME ist? Wenn ich dort vorher Dateien hingeschoben habe, deren Eigentümereigenschaften und Zugriffsrechte eigentlich Manipulationen nicht zulassen, sollte er an diesen Dateien auch nicht herumspielen dürfen.

WICHTIG:

Ich habe eben festgestellt, dass die Zugriffsrechte alle greifen, wenn USER sich über eine Shell einloggt. Soll heissen, dass er in eine unter /home/ftp liegende ihm gehörende Datei schreiben kann usw, AUCH WENN /home/ftp/ für OTHER "nur" r-x ist.

Gleichzeitig kann er NICHT eine dort befindliche Datei editieren, wenn er nicht Owner ist und nicht der Gruppe angehört. Genau SO soll es sein und müsste dies auch beim FTP-Login praktiziert werden.

ABER: Loggt sich USER mittels FTP in den ProFTPs-Server bei unveränderten Dateirechten ein, werden o.a. Rechte - wie von mir schon ausführlich beschrieben - nicht befolgt.

Ich will nicht hoffen, dass es sich am Ende doch um einen Bug von ProFTP 1.3.0 handelt, der bei mir im Einsatz ist.

Nette Gruesse
testit

 

[Flex6]

die variante ist eh schon unsicherer, da alle ftp-user ein verzeichnis benutzen und das sollte eigentlich vermieden werden, du kannst noch eins probieren mit rechte 1755 , so das nur benutzer mit den dateie-rechten etwas verändern kann
für was ist das ftp-home gedacht, zum upload auf webverzeichnis etc.

 

[rosa]

Mir ist nicht klar, wie Du darauf kommst, dass er alles in /home/ftp darf, selbst, wenn dieses Verzeichnis sein $HOME ist? Wenn ich dort vorher Dateien hingeschoben habe, deren Eigentümereigenschaften und Zugriffsrechte eigentlich Manipulationen nicht zulassen, sollte er an diesen Dateien auch nicht herumspielen dürfen.

Leg doch mal was in deinem $HOME mit root was an was nicht dir gehört und probiere es zu löschen, es wird gehen. Dein Home ist die Heimat und da hast DU das sagen.

Ich habe eben festgestellt, dass die Zugriffsrechte alle greifen, wenn USER sich über eine Shell einloggt. Soll heissen, dass er in eine unter /home/ftp liegende ihm gehörende Datei schreiben kann usw, AUCH WENN /home/ftp/ für OTHER "nur" r-x ist.

Gleichzeitig kann er NICHT eine dort befindliche Datei editieren, wenn er nicht Owner ist und nicht der Gruppe angehört. Genau SO soll es sein und müsste dies auch beim FTP-Login praktiziert werden.

mein reden, nichts anderes habe ich geschrieben. Du hattest aber 770 in deinem Beispiel. Worauf dir von s-tlk und mir gesagt worden ist das Du ein "5" noch brauchst.

ABER: Loggt sich USER mittels FTP in den ProFTPs-Server bei unveränderten Dateirechten ein, werden o.a. Rechte - wie von mir schon ausführlich beschrieben - nicht befolgt.

Ich kenne nun ProFTP nicht wirklich gut, aber der kann ja auch mit eigenen UsersDBs umgehen, und läuft selber als root. Womit ich sagen will das der ganz unabhängig von deinen gesetzten Rechten machen und tuen kann was er will je nach dem wie er Konfiguriert ist.

Ich will nicht hoffen, dass es sich am Ende doch um einen Bug von ProFTP 1.3.0 handelt, der bei mir im Einsatz ist.

Ich bezweifle das dies ein Bug ist, denn bis jetzt fahnde ich alles was Du geschrieben hast als "normales" verhalte.

 

[testit]

die variante ist eh schon unsicherer, da alle ftp-user ein verzeichnis benutzen und das sollte eigentlich vermieden werden, du kannst noch eins probieren mit rechte 1755 , so das nur benutzer mit den dateie-rechten etwas verändern kann
für was ist das ftp-home gedacht, zum upload auf webverzeichnis etc.

Hi,

nein, natürlich landen NICHT alle user im gleichen ftp-Verzeichnis. Das habe ich auch nicht behauptet. Das Verzeichnis könnte auch /www/htdocs/XYZ heissen.

Es existiert halt schon ein Verzeichnis, auf das ich jemandem FTP-Zugriff geben will, da ich keine Lust habe mit SFTP und Chroot eine "Einsperrlösung" zu realisieren.

Danke fuer den Tip - werde es probieren!


Gruss
testit

 

[testit]

Leg doch mal was in deinem $HOME mit root was an was nicht dir gehört und probiere es zu löschen, es wird gehen. Dein Home ist die Heimat und da hast DU das sagen.



mein reden, nichts anderes habe ich geschrieben. Du hattest aber 770 in deinem Beispiel. Worauf dir von s-tlk und mir gesagt worden ist das Du ein "5" noch brauchst.

Du hast in einem Deiner vorangegangene Beiträge oben geschrieben:

Und was wundert dich daran? Er ist nicht Eigentümmer noch Gruppenzugehöriger also fält er unter "Andere". Hat Andere aber nur lese Rechte kann er natürlich auch nur lsen und nicht schreiben.

Genau DAS trifft eben hier komischerweise nicht zu: USER kann via SHELL so arbeiten, wie man es aufgrund der Zugriffsrechteregelung erwartet. Also: Auch ihm gehörende Dateien unter /home/ftp beschreiben, obwohl /home/ftp 770 ist.

Nur bei ProFTP greift dies nicht.

Ich kenne nun ProFTP nicht wirklich gut, aber der kann ja auch mit eigenen UsersDBs umgehen, und läuft selber als root. Womit ich sagen will das der ganz unabhängig von deinen gesetzten Rechten machen und tuen kann was er will je nach dem wie er Konfiguriert ist.

Und wozu sind Deiner Ansicht nach Direktiven wie

# Benutzer und Gruppe festlegen unter der ProFTP laufen soll
User ftpuser
Group ftpuser
gut?

Natürlich könnte ProFTP, wenn er unter Root läuft, alles mögliche machen, aber Du wirst mir doch sicher Recht geben, dass es wohl kaum angedacht ist, dass er gesetzte Zugriffsrechte für die eingeloggten User nicht beachtet, oder?

Und da ein Einloggen von USER über eine Shell genau die erwartete Verhaltensweise bzgl. gesetzter Rechte zeigt, ist es komisch, dass dies bei Einloggen dieses User auf ProFTP nicht der Fall ist.

Ich bezweifle das dies ein Bug ist, denn bis jetzt fahnde ich alles was Du geschrieben hast als "normales" verhalte.

Ich nicht ;-)

Gruss
testit

 

[0815Chaot]

ProFTP habe ich noch nie benutzt, da mußt du halt einfach die Dokumentation lesen, wie das mit den Zugriffsrechten gehandhabt wird. Aber zu den allgemeinen UNIX-Zugriffsrechten, die einigen hier wohl doch noch nicht so ganz geläufig zu sein scheinen:

Leg doch mal was in deinem $HOME mit root was an was nicht dir gehört und probiere es zu löschen, es wird gehen. Dein Home ist die Heimat und da hast DU das sagen.

Das ist, gelinde gesagt, Schwachsinn. Bevor du anderen sagst, sie sollten sich noch mal mit den UNIX-Zugriffsrechten auseinandersetzen, solltest du das erstmal selbst tun. Es ist nämlich völlig egal, ob ein Verzeichnis das $HOME von irgendwem ist, einzig und allein die aktuellen Zugriffsrechte sind entscheidend. Mach mal

chmod 000 $HOME

und sieh nach, ob du immer noch der Herr in deinem $HOME bist... Da geht erstmal nix mehr. Natürlich kannst du die Zugriffsrechte anschließend wieder auf 700 setzen, weil du der Eigentümer deines $HOME zu sein scheinst, und danach kannst du wieder nach Belieben in deinem $HOME rumschreiben. Im vorliegenden Fall ist das aber ganz und gar nicht klar, da hier offensichtlich munter mit Eigentums- und Zugriffsrechten herumprobiert wurde. Da hilft es überhaupt nicht, daß /home/ftp möglicherweise das $HOME irgendeines Benutzers ist.

Genau DAS trifft eben hier komischerweise nicht zu: USER kann via SHELL so arbeiten, wie man es aufgrund der Zugriffsrechteregelung erwartet. Also: Auch ihm gehörende Dateien unter /home/ftp beschreiben, obwohl /home/ftp 770 ist.

Genau das würde man eben NICHT erwarten. Wenn USER weder Eigentümer noch Mitglied der Gruppe von /home/ftp ist und /home/ftp die Zugriffsrechte 770 hat, dann darf er an den Inhalt dieses Verzeichnisses überhaupt nicht rankommen.

Mir ist nicht klar, wie Du darauf kommst, dass er alles in /home/ftp darf, selbst, wenn dieses Verzeichnis sein $HOME ist? Wenn ich dort vorher Dateien hingeschoben habe, deren Eigentümereigenschaften und Zugriffsrechte eigentlich Manipulationen nicht zulassen, sollte er an diesen Dateien auch nicht herumspielen dürfen.

Ob jemand Dateien löschen oder umbenennen darf, ist eine Eigenschaft des Verzeichnisses, in welchem die Datei liegt. Das hat mit der Datei selbst überhaupt nichts zu tun. Ausnahme: Bei einem Verzeichnis ist das Sticky-Bit gesetzt. Die Eigentümerschaft an einer Datei berechtigt nur, an den Zugriffsrechten dieser Datei rumzuspielen und ggf. ihre Gruppenzugehörigkeit zu ändern. Die Zugriffsrechte der Datei selbst wiederrum beziehen sich nur auf den Datei-Inhalt.

Sobald /home/ftp auf 775 steht, hat USER zwar die Möglichkeit unter /home/ftp Daten zu lesen, aber er kann keine dorthin transferieren, weil er als USER weder Eigentümer noch Gruppenangehöriger von /home/ftp ist. Erst, wenn man /home/ftp so chmodded, dass "Others" auf rwx steht, hat er auch das Recht, unter /home/ftp nicht nur zu lesen, sondern auch zu schreiben.

Klar, um Dateien in einem Verzeichnis anzulegen, braucht man Schreibrechte auf das Verzeichnis.

Das vorliegende Problem ist auch vorher nie bei mir aufgetaucht und erst jetzt deutlich geworden, weil ich einen FTP-Account für einen User angelegt habe, der auf eine ganz bestimmte Datei in seinem FTP-Zielverzeichnis keinen Zugriff haben soll (ein symbol. Link).

Wo da jetzt genau das Problem liegt, kann man aus der Beschreibung nicht erkennen. Zu beachten ist aber, daß symbolische Links immer die Zugriffsrechte 777 haben. Entscheidend für den Zugriff sind nämlich immer die Zugriffsrechte der Datei, auf welche der Links verweist.

Also ich würde vorschlagen, daß du dich nochmal genauer mit der Thematik beschäftigst und dann die Zugriffsrechte auf Shell-Ebene wie gewünscht setzt. Wenn du auf Shell-Ebene das gewünschte Verhalten realisiert hast, kannst du dich dem ProFTP widmen. Vielleicht ist es ja nicht mal ein Bug, sondern ein vom Entwickler beabsichtigtes Verhalten. Deswegen solltest du da auch noch mal in die Doku sehen.

Wenn du immer noch Probleme mit der Umsetzung hast, dann brauchen wir auf jeden Fall mal die Ausgabe von ls -al /home/ftp - alles andere bringt nicht wirklich was.

 

[rosa]

Das ist, gelinde gesagt, Schwachsinn. Bevor du anderen sagst, sie sollten sich noch mal mit den UNIX-Zugriffsrechten auseinandersetzen, solltest du das erstmal selbst tun. Es ist nämlich völlig egal, ob ein Verzeichnis das $HOME von irgendwem ist, einzig und allein die aktuellen Zugriffsrechte sind entscheidend. Mach mal

chmod 000 $HOME

und sieh nach, ob du immer noch der Herr in deinem $HOME bist... Da geht erstmal nix mehr.

Ich habe das aber ein klein bisschen freundlicher geschrieben und auch nicht behauptet das er Schwachsinn von sich gibt. Mir kamm es nur merkwürdig, wie auch geschrieben, vor das man Dateien (in dem Fall PHP) mit 777 versieht, aber natürlich kann das auch Sinn machen. Auch habe ich nicht vom HOME Selber geschrieben sondern innerhalb dessen, ok ich kann mich irren das es nichts mit dem Home zu tun hat was ich auch getan habe, es wahr von mir selber aber auch mit einem Fragezeichen versehen, aber ganz schwachsinn ist dies was ich geschrieben habe nicht:

# cd /home/as
# touch bla
# chmod 000 bla
# exit
exit
> echo ~
/home/as
> cd ~
> rm bla
override ---------  root/wheel for bla? y
> ls bla
ls: bla: No such file or directory

Schönen Abend noch.

 

[0815Chaot]

es wahr von mir selber aber auch mit einem Fragezeichen versehen

Nicht wirklich:

kann es sein das /home/ftp vom USER das $HOME ist? weil dann darf er natürlich alles.

Wenn man sich nicht sicher ist, dann verwendet man nicht Wörter wie "natürlich".

Auch habe ich nicht vom HOME Selber geschrieben sondern innerhalb dessen

Du hast das Prinzip anscheinend immer noch nicht verstanden. Ob du eine Datei löschen, anlegen oder umbenennen kannst, hat nichts mit den Zugriffsrechten auf die Datei zu tun. Das habe ich in meinem Post zweimal geschrieben. Entscheidend sind die Zugriffsrechte auf das Verzeichnis, in welchem die Datei liegt. Ob dieses Verzeichnis nun dein Heimatverzeichnis ist oder nicht, ist dafür völlig irrelevant. Wenn du chmod 000 $HOME machst, kannst du in deinem $HOME überhaupt nichts mehr machen. Dann ist es auch völlig egal, welche Zugriffsrechte die Dateien in deinem $HOME haben mögen, an die kommst du dann erst gar nicht ran.

# chmod 000 bla

Für die Sache selbst unerheblich.

override --------- root/wheel for bla? y

Und diese Rückfrage kannst du auch noch unterdrücken, indem du rm(1) mit dem Schalter -f aufrufst.

Versuch doch übrigens mal, dein $HOME zu löschen. Das wird mit den Standard-Zugriffsrechten von /home nicht gehen. Du kannst den Inhalt deines $HOME beliebig löschen, aber nicht das $HOME selbst.

UNIX-Basics, BTW.

 

[rosa]

Wie schon geschrieben, ja ich habe mich geirrt was das mit dem $HOME angeht, sorry! Und meine Formulierung wahr auch nicht gerade gut gewählt, ja.

Deswegen schrieb ich ja in einem meinem Posts vor her "überschreiben". Da das Verzeichnis aussen mir dieses erlaubt, wo rauf du ja genau mit deinem $HOME löschen hinaus willst da hier die Rechte von /home mir genau dieses Default nicht erlauben. Das ist mir genauso bewusst wie der Schalter -f. Aber danke.