verwirrendes rechteproblem

Z

Zico

Lebende Foren Legende
Hallo Leute

Heut hat mich etwas schwer verwirrt und ich hoffe Jemand von euch kann das aufklären.

Folgende Situation:
Wir müssen mit einem alten SuSE 7.1 allerhand Server auf eine fiktionale Firma aufsetzen. Da gibt es jede Menge Firmenordner in dem fast jeder Nutzer andere Rechte hat, so, dass die normalen Linux Nutzerrechte beinahe nicht mehr ausreichen um alles zu ermöglichen, wie es gefordert wird (bei Interesse häng ich gern die Nutzermatrix mit an, es is wirklich verzwickt).
Soweit alles kein Problem, war alles lösbar.

Nun stand ich vor der Aufgabe einen Share Verzeichnis einzurichten, in welchem JEDER nutzer lesen, aber nur die von ihm selbst erstellten Dateien schreiben darf.
Ich habe also ein Verzeichnis erstellt und es mit den Rechten

0777

versehen um jedem Vollzugriff auf das Verzeichnis zu gewährleisten. Klappt auch. Dann habe ich mit Nutzer1 eine Datei erstellt, welche standardmäßig mit den Rechten 0644 ausgestattet ist. Sprich, nur er darf die Datei verändern. Dann habe ich mich mit Nutzer2 angemeldet und ich konnte die Datei erfolgreich löschen.
Ungläubig habe ich eine weitere Datei erstellt und sie mit den Rechten
0700 versehen. Nutzer2 konnte die Datei daraufhin wie erwartet nicht mehr lesen. Löschen konnte er sie dennoch.
Ich dachte schon es sei ein Problem mit dem Verzeichnis und habe ein neues angelegt - jedoch selbes Spiel.
Dann habe ich das ganze nochmal in /tmp versucht, welches ebenso mit 0777 bestückt ist. Dort konnte Nutzer2 die Datei NICHT löschen.
HAt dazu jemand eine Erklärung?
Wie schon gesagt, es handelt sich hierbei um SuSE7.1 mit Ext2 als FS.
 
Sticky-Bit, bewirkt bei Verzeichnissen, dass jeder Benutzer nur seine eigenen Dateien löschen kann.
Code:
chmod +t <verzeichnisname>

Aufgeklärt?
 
Das mag ja ne Lösung sein, aber warum kann ein Nutzer eine Datei löschen obwohl er keie Rechte darauf hat? Leserechte konnte ich dem Nutzer auf die Datei entziehen, Schreibrechte anscheinend jedoch nicht. Gibts dafür ne Erklärung?
 
Der Benutzer hat aber Schreibrechte für das Verzeichnis, was bedeutet, dass er bestimmen kann, was in dem Verzeichnis drinsteht.
Wenn man sich Verzeichnisse als Dateien vorstellt, die eine Liste enthalten, auf der Dateinamen zu Inodes zugeordnet werden, dann wird das ganze vielleicht klarer.
 
Ok und warum kann er die Datei dann nicht lesen?
Die Rechte sind 0700 für die Datei und 0777 für den Ordner also entweder müsste er denn nach der Theorie lesen UND schreiben können oder nach den Dateirechten bestimmt nichts von beidem. Doch er kann die datei NICHT lesen aber doch schreiben.
Zudem hat der Ordner /tmp die selben Rechte und da darf der Nutzer2 bei den selben Rechten WEDER lesen noch schreiben.
 
Zuletzt bearbeitet:
Sicher, dass er schreiben kann?
Denn schreiben ist technisch etwas vollkommen anderes als löschen.
Was passiert also z.B. bei "echo "blah" > datei" wenn du keine Schreibrechte hast?
 
Auch wenn ich mich nun blamiere aber:
Ich dachte bisher immer, wenn ein Nutzer keine Schreibrechte hat, darf er die Datei auch nicht löschen?!
Ich habs bisher immer nur mit löschen der Datei versucht....

EDIT: Dateinamen ändern geht auch.
 
Zuletzt bearbeitet:
Kann passieren sowas, und es erscheint einem ja auch nicht gleich unlogisch, funktionieren tut es wie so oft aber eben doch anders.
Man lernt halt immer dazu ;)
 
Nun bin ich noch verwirrter als zuvor:
Hab gerade hier ein ekleine testdatei als root erstellt und
chmod +t testfile
gemacht. also hatte ich dann:
-rw-r--r-T 1 root root 0 2006-05-11 21:33 testfile
Dennoch konnte ich es als User löschen.
 
Das "chmod +t" muss auf das Verzeichnis in dem die Datei ist, nicht auf die Datei, dann sollte es funktionieren.
 
Kann ich denn auch eine einzelne Datei direkt vor dem Löschen schützen?
(Sorry wegen den Fragen, komme mir wirklich grad extrem doof vor)
 
Also zumindest mir ist keine Methode bekannt, es würde auch eigentlich der Logik des Dateisystems wiedersprechen.
Es kann sein, dass so etwas mit ACLs geht, aber wenn, dann hab ich davon keine Ahnung :D
(haut mich, falls ich Blödsinn erzähle)
 
Danke nochmal für die Antworten. Ich hab mir nun mal die ganzen anderen Rechtarten angesehn. Damit kann man ja echt noch ne Menge mit basteln. Hmpf - wie wenig ich doch da weiss :(
 
@ Zico:

+t bringt dir ja nicht viel auf eine Datei, den da reicht das normale Rechtesystem unter Linux vollkommen aus.

+t wird z.B. von /tmp/ verwendet, weil hier jeder seine eigenen Dateien ablegen soll aber nicht andere löschen.
 
Wenn +t unnütz wär und das normale System ausreichen würde um seine Datei vorm löschen zu schützen dann äh wäre die Frage doch erledigt.
Ist sie ja aber nicht :D
 
Bevor hier noch irgendwer (weiter) unsinn verbreitet, kommt hier mal der Auszug aus "man chmod"

STICKY FILES
On older Unix systems, the sticky bit caused executable files to be
hoarded in swap space. This feature is not useful on modern VM sys-
tems, and the Linux kernel ignores the sticky bit on files. Other ker-
nels may use the sticky bit on files for system-defined purposes. On
some systems, only the superuser can set the sticky bit on files.

STICKY DIRECTORIES
When the sticky bit is set on a directory, files in that directory may
be unlinked or renamed only by root or their owner. Without the sticky
bit, anyone able to write to the directory can delete or rename files.
The sticky bit is commonly found on directories, such as /tmp, that are
world-writable.
 
Leute,

die Sache ist weder kompliziert noch unlogisch. Der Punkt ist einfach, dass für das System alles eine Datei ist.
Wenn ich jetzt auf eine reguläre Datei (also z.B. ein Textfile) Leserecht habe, dann kann ich mir den Inhalt anschauen, wenn ich darauf Schreibrecht habe, kann ich den Inhalt ändern. Soweit klar, oder?
Wenn ich auf ein Directory Leserecht habe, kann ich den Inhalt anschauen, wenn ich darauf Schreibrecht habe, kann ich den Inhalt ändern. Immer noch klar, oder?
Inhalt ändern heißt beim Verzeichnis einfach: Dateien anlegen, umbenennen oder löschen.

Und ja, es gibt ein Sticky-Bit für Verzeichnisse, das das Löschrecht einschränkt. Wenn es gesetzt ist, kann ein Benutzer nur noch die Dateien löschen, die ihm selbst gehören (es sei denn, er ist root).

Und ja, es gibt auch eine Möglichkeit (jedenfalls mit den Dateisystemen ext2/3 und xfs), Files komplett immun zu machen oder nur appendable. Dazu gibt es Attribute. Bitte lies das Manual zu chattr und lsattr. Ein File macht man komplett immun mit:

chattr +i dateiname

Dann kannst Du es nicht mehr löschen, aber auch sonst nichts mehr damit machen, weder einen Hardlink darauf anlegen noch sonst was.

Gruß.
 

Ähnliche Themen

Schreibzugriff verweigert (SLES 11 / Client: Windows XP)

[Debian Lenny] Dateirecht Problem

Ubuntu 6.06.1 und samba3 Zugriffsrechte wiedersprechen sich

Zurück
Oben