Diskussion:Chmod

a

Zitat Artikel:

Wenn wir jetzt einer Datei alle Executerechte fuer alle Benutzer geben wollen, reicht ein a+x datei.

... besser wäre: chmod a+x datei.

am i right?

außerdem: a habe ich mir als all hergeleitet... aber was bedeutet das +?

danke, --Abdull 15:11, 4. Mär 2005 (CET)

S-Bit mit chmod

Die Tabelle mit den Rechten sollte um die S-Bit Rechte erweitert werden, so koennte solch eine Tabelle entstehen

Bezeichnung	u			g			o
Zugriffsrechte	r	w	x	r	w	x	r	w	x
Wertigkeit	4	2	1	4	2	1	4	2	1
S-Bit Wertigkeit	4			2			1

Dann noch eine Beschreibung, was welches S-Bit macht, wo sie in einem "ls" Befehl auftauchen und wie man sie setzt (chmod 1777 /tmp)

Guter Vorschlag, sei mutig! --jpp ?! 09:50, 25. Jan 2006 (CET)

Benutzergruppen definieren

In dem Artikel fehlt eine Definition der Bentutzergruppen. Was unterscheidet z. B. den Owner von World (identifizierter ftp-Zugang?) und wer gehört zur Gruppe? Da die chmod-Werte oft auch von nicht-Unix-Usern eingestellt werden müssen, ist diese Erklärung hier sicher angebracht. --Rob 10:59, 30. Aug 2006 (CEST)

Hallo,

ich finde, die klassischen Unix-Dateirechte haben im chmod-Artikel nichts zu suchen, denn der Artikel sollte ja eigentlich das Programm chmod beschreiben. Vor allem im deutschen Artikel ist das nicht der Fall (im englischen hingegen ist das schon eher so). Ich denke das Thema hat in der deutschen WP deutlich Aufholbedarf.

Das Argument, dass "nicht-Unix-User" Unix-Dateirechte bearbeiten, halte ich hier für nicht angebracht. Bitte denke daran, dass das hier kein Tutorial sein soll. Insbesondere bei so ganz typisch Computerendbenutzerthemen, die vor allem auch eine relativ breite Masse betreffen, habe ich das Gefühl, dass oft Halbwissende aus einem Artikel eher eine tutorialartige "So machst du xyz unter windows"-Sammlung machen wollen. Meiner Meinung nach braucht eine Enzyklopädie jedoch eine objektive Erklärung eines Lemmas mit Betonung auf wesentlichen Dingen und keinen ausschweifenden Problemlösungen in ganz spezifischen Fällen. Das ist eher was für den "Weblinks"-Abschnitt ganz unten :-)

Grüße, --Benji 19:54, 29. Jan. 2007 (CET)

Ich gebe dir im Grundsatz recht, sehe aber auch, dass dann nicht viel von diesem Artikel übrig bleibt. Aber fang gerne an die Tutorialteile rauszuschmeissen, meine Unterstützung hast du dafür. --Trublu ?! 20:34, 29. Jan. 2007 (CET)

Ich stelle mir momentan folgendes vor: Einen neuen Artikel, Unix-Dateirechte, in den die entsprechenden Teile kommen. chmod wird natürlich schlanker, aber könnte dann mit den eigentlich wesentlichen Informationen ausgestattet werden, und zwar

• Benutzung des Programms (wie en:chmod)
• Besondere Betonung auf dem speziellen Syntax für schnelles Rechtevergeben (sowas wie chmod a+x ..., was ja überhaupt nichts mit Unix-Dateirechten an für sich zu tun hat)

Außerdem würde ich auf Unix-Dateirechte beim Thema ACLs, Dateiattributen und an vielen anderen Stellen verlinken, wo der Link nach chmod wirklich deplaziert wäre, die Infos zu den Dateirechten allerdings nicht.

Ggf. könnten Artikel wie Sticky Bit direkt einfließen und durch einen Redirect ersetzt werden.

Was hältst du davon? Mir würde das gefallen :-)

Grüße, --Benji 21:17, 30. Jan. 2007 (CET)

Sticky ohne o+x macht keinen Sinn?

Im Artikel lese ich: "Ein großes T bedeutet ein gesetztes Sticky-Bit, ohne gesetztes Execute-Bit. Da diese Kombination i. A. keinen Sinn hat, wurde die Darstellung mit großem T gewählt, da sie so sehr auffällig ist." - Was mir daran nicht klar ist: wenn das Stickybit für alle Gruppen gilt, warum soll es dann keinen Sinn machen, wenn world keine Execute-Rechte hat? --Martin von Wittich 00:59, 27. Jan. 2007 (CET)

i. A.

Was bedeutet i. A.? Die Abkürzung kommt sowohl unter SUID bzw. SGID als auch unter Sticky-Bit im vorletzten Satz vor.

Da diese Kombination i. A. keinen Sinn hat, wurde die Darstellung mit großem T gewählt, da sie so sehr auffällig ist.

Die Bedeutung der Abkürzung lässt sich für mich nicht erkennen.

Es soll wohl "Im Allgemeinen" heissen. --Trublu ?! 14:21, 11. Mär. 2007 (CET)

Es heißt auch "im Allgemeinen". Da die SUID-, SGID- und Stiyk-Bits die Bedeutung einer ausführbaren Datei, oder eines ("betretbaren") Verzeichnisses beeinflussen, ist ihre ursprüngliche Semantik nur bei gesetztem X-Bit zutreffend. Nichtsdestotrotz ist es möglich, dass ein Programm bei einer Datei eines dieser Bits setzt, obwohl das X-Bit nicht gesetzt ist. Dies mag dann eine bestimmte, nur eben von diesem Programm verstandene Markierung an dieser Datei sein. Mir ist kein Programm bekannt, was derartigen "Missbrauch" von den Permissionbits betreibt. Aber... möglich wäre es. --RokerHRO 10:50, 12. Mär. 2007 (CET)

Umstrukturierung des Unix-Dateirechte-Bereichs

Hallo,

wie bereits oben angekündigt habe ich heute mein Vorhaben, den Artikel Unix-Dateirechte zu gründen, umgesetzt. Die überwiegenden Teile von chmod sind dorthin umgezogen, jener Artikel wurde auch maßgeblich durch en:File_system_permissions beeinflusst. Viel blieb dann für chmod nicht mehr übrig - das zeigt doch ganz heftig, wie sehr der Artikel bis jetzt an dem eigentlichen Lemma vorbei ging. Daher habe ich ihn aufgefüllt, und zwar mit relevantem Inhalt: Dieser "Kurznotation" für Dateirechte (a+rx...), die vorher nur in einem Satz angesprochen wurde, wird jetzt, wie es sich gehört, ordentlich erwähnt. Beim Artikelaufbau ließ ich mich auch hier wieder von en:chmod inspirieren.

Außerdem gibt es noch zahlreiche andere Artikel, die irgendwie in die Richtung Unix-Dateirechte abdrehen:

• Setuid, Setgid, Sticky Bit sind drei, die ich vorher eigentlich in Unix-Dateirechte einbauen wollte, aber weil die englische Wiki das auch nicht macht, habe ich mich umentschieden: Lieber diese Artikel ausbauen und sauber umstrukturieren.
• x-Bit ist ein ziemlich trauriger Artikel (auch kaum verlinkt), den man eigentlich in Unix-Dateirechte einfließen lassen könnte. Allerdings erschrickt mich hier, wie alt der Artikel schon ist (die Arbeit so brutal zerstören...), und die Erklärung des x-bit-Hacks würde so auch wegfallen. Die könnte man allerdings wiederum in SSI einfließen lassen, weil sie eine sehr beschränkte Verwendung betrifft. Meine momentane Gesinnung lautet hier also: Einarbeitung in andere Artikel + Löschung + Referenzen umändern (sind nämlich nur 4 Artikel). Wie ist hier die Meinung davon?

Grüße, --Benji 22:22, 11. Mär. 2007 (CET)

PS: Was momentan noch fehlt, sowohl unter Unix-Dateirechte als auch chmod, sind im Wesentlichen aussagekräftige Beispiele (darauf hatte ich jetzt keine Lust mehr). Fühlt euch frei, tätig zu werden :-)

Weblinks

@jpp: Sieht etwas nach versehen aus, aber ich wollte tatsächlich alle löschen. Hier mit Begründung

• POSIX-Spezifikation des chmod-Tools: [1]
• manpage zu chmod: [2]

Beides Manpages (mehr oder weniger), damit mindestens einer überflüssig. Manpages sind aber mMn nicht als weiterführenden Links geeignet.

• http://www.linux-user.de/ausgabe/2000/10/093-zubefehl/befehl9.html

Anleitung, kein Mehrwert an Infos.

• Linux-Fibel

ein kurzer Absatz, weniger Infos als dieser Artikel.

• Online-Tools zur Berechnung von Dateirechten: [3], [4]

Online-Tools, also keine Infos, sondern "umrechnung", zum einen verdoppelung, zum anderen vollkommen überflüssig.

--Trublu ?! 15:44, 15. Aug. 2007 (CEST)

Es ist üblich, Manpages als weiterführende Informationen einzutragen. Mal ganz pragmatisch: Was möchte jemand nach Lektüre des Artikels wissen, um mehr zu erfahren? Natürlich, wie er den Befehl verwendet. Bei den übrigen Links stimme ich dir zu. Vorschlag: Die „offizielle“ POSIX-Manpage drinlassen, die übrigen Links entfernen. --jpp ?! 16:59, 15. Aug. 2007 (CEST)

Bin ich nicht ganz glücklich mit, kann das aber akzeptieren. --Trublu ?! 17:26, 15. Aug. 2007 (CEST)

Erklär mir doch bitte nochmal kurz, warum du eine Spezifikation nicht für weiterführende Information hältst. Gegen welche Konvention von Wikipedia:Weblinks wird deiner Meinung nach verstoßen? --jpp ?! 18:35, 15. Aug. 2007 (CEST) PS: Was mich viel mehr stört, ist dass der Artikel keine Quellen nennt.

"Bitte vom Feinsten!" Ich würde diesen Link halt nicht als einen solchen bezeichnen. Aber wie gesagt, mit diesem Kompromiss kann ich leben. Zur Quelle: Manpage bzw. chmod selber (chmod --help), wüsste nicht wie man das am besten als References macht. Vielleicht einfach den Abschnitt Weblinks in Quellen umbenennen. --Trublu ?! 19:30, 15. Aug. 2007 (CEST)

Also ich würde die POSIX-Spezifikation sogar als vom Allerfeinsten bezeichnen, denn es ist die Referenz. --jpp ?! 21:51, 15. Aug. 2007 (CEST)

777

Es werden diverse sachen nicht erklärt:

• Was bedeuted das ?
• Wie kommt die Zahl zustande ?

--Arcy 08:39, 16. Nov. 2007 (CET)

Hab ich mir auch überlegt, allerdings findet sich das bereits unter den Unix-Dateirechten recht genau beschrieben --zwutz 02:53, 27. Dez. 2007 (CET)

Die beiden Artikel sollten zusammengelegt werden. --Arcy 13:05, 27. Dez. 2007 (CET)

Nein! Ich habe diese beiden Artikel erst in mühevoller Arbeit auseinandergefiddelt - so zusammengepanscht war es nämlich vorher.

Unix-Dateirechte werden nicht nur bei dem Programm chmod benutzt, sondern streifen auch viele andere Gebiete, vor allem Windows/DOS-Benutzer kommen mit ihren FTP-Clients mit der Unix-Welt und ihren Dateirechten in Berührung. Dateirechte werden nicht nur von diesem Konsolenprogramm gesetzt, sondern auch von grafischen Programmen; sie betreffen Dateisysteme und alle möglichen anderen Gebiete. Das umfassende Thema Unix-Dateirechte einfach mit dem bekannten CLI-Programm chmod zusammenzupacken macht die gesamte Sache wesentlich unübersichtlicher.

Auf den Artikel Unix-Dateirechte wird an mehren Stellen verwiesen, auf Notationen wie "777" wird doch sogar im Zuge der unterschiedlichen Notationstypen eingegangen. Was bleibt jetzt noch unklar? Wo kann der Artikel verbessert werden?

--Benji 16:26, 27. Dez. 2007 (CET)

Da kann ich Benji nur zustimmen. Unix-Dateirechte haben mit chmod nicht mehr zu tun als XSLT mit Xalan. --j ?! 16:29, 27. Dez. 2007 (CET)

Der insgesamt recht kurze Artikel verweist 5 x intern auf den Artikel "Unix-Dateirechte". Die "graphischen Alternativen" werden zudem sogar vollständig im Artikel "Unix-Dateirechte" behandelt. Der Logik hier folgend hat die Besprechung der "graphischen Alternativen", im Artikel "Unix-Dateirechte" auch nichts zu suchen, da diese ebenfalls Programme wie chmod darstellen. --Arcy 20:14, 27. Dez. 2007 (CET)

Sie werden ja nicht beschrieben, sondern kurz erwähnt. So wie dort auch chmod kurz erwähnt wird. --j ?! 20:48, 27. Dez. 2007 (CET)

Na ja Bildschirmkopien von Dateimanagern und die Beschreibung der graphischen Oberfläche sucht man imho eher auf der Anwendungsebene bzw. bei dem Befehl chmod.
Chmod ist imho eine der wichtigsten Facetten des Themas "Unix-Dateirechte" und untrennbar damit verwoben. Eine Weiterleitung und Besprechung dort käme dem Thema zugute.
Die symbolische Notation wird in beiden Artikeln behandelt. Die numerische Notation wiederum nur im Artikel "Unix-Dateirechte". Auch graphische Oberflächen werden wiederum "breiter" eher im Artikel "Unix-Dateirechte" unter "Beispiele" graphisch abgehandelt/wiedergegeben. Der Abschnitt "Grafische_Alternativen" findet sich doppelt in beiden Artikeln.
Es bleibt letztendlich nur der kurze Einleitungssatz sowie der Abschnitt "Benutzung", in dem sich originäre Informationen zu chmod wiederfinden. --Arcy 21:22, 27. Dez. 2007 (CET)

Ich finde Jpps Vergelich mit XSLT und Xalan recht gut. Wieso sollten auf Xalan andere Prozessoren vorgestellt werden? Dies geschieht auch hier auf Unix-Dateirechte, der Hinweis auf chmod ist doch völlig ausreichend. Wenn dir etwas nicht passt, dann bist du herzlich eingeladen, es umzuschreiben, solange du nicht die klar getrennten Kompetenzen der beiden Artikel wider miteinander vermischt.

Die ganzen Notationsformen sind in der Tat verwirrend. Prinzipiell werden alle allgemeingültigen Notationsformen, weil z.B. von ls, ... verwendet, in Unix-Dateirechte abgehandelt. Nun hat chmod aber eine zusätzliche, programmspezifische "Kurznotation", die du eben nicht in ls, Konqueror oder Nautilus antreffen wirst. Deswegen gehört sie nach chmod und *nicht* nach Unix-Dateirechte.

Beispiele für die Verwendung des Programmes chmod gehören natürlich in diesen Artikel, allgemeine Beispiele zum Konzept der Dateirechte natürlich nach Unix-Dateirechte.

Vergleichen wir also mal den Inhalt von chmod mit Unix-Dateirechte und versuchen darauf hin, chmod zusammen zu streichen, fällt auf:

chmod	Unix-Dateirechte
Einleitung: Programm	Grundlagen des Konzepts: Unix-"Benutzerklassen", grundlegende Definition von "Rechten"
Benutzung symbolische Kurznotation Beispiel für Benutzung	Notation von Rechten Oktalnotation symbolische Notation grafisch aufgearbeitete Beispiele
Ausblick: Grafische Alternativen	So kommt der Benutzer mit dem Konzept in Berührung: Programme zum Bearbeiten der Rechte

Noch Fragen? Ich verweise übrigens auf Diskussionen weiter oben auf dieser Seite, wo das Thema bereits mehrfach auseinandergetreten wurde. Ich habe schließlich die Initiative ergriffen und einen Artikel Unix-Dateirechte entwickelt, um die Missstände, die sich aus den verschiedenen, dieses Thema schneidenden Artikeln, bildeten, zu beseitigen. Eigentlich ging ich davon aus, dass das Konzept auf Zustimmung treffen würde und man dieses Grundgerüst weiter ausbauen würde (ich finde, Unix-Dateirechte liest sich recht trocken), statt das ganze wieder Rückgängig machen zu wollen. Es geht hier nicht nur um chmod, sondern auch viele andere Artikel, siehe oben.

--Benji 01:38, 28. Dez. 2007 (CET)

Der Vergelich mit XSLT und Xalan passt IMHO nicht. Xalan ist ein Programm unter vielen. Wie viele Unix Befehle existieren zusätzlich zu Chmod, mit denen ich das gleiche erreichen kann? Auch die erwähnten Artikel Nautilus etc. schweigen sich größtenteils zu diesem Thema aus.
Zur Notation bei den Dateirechten; Notationen werden von Programmen zur Darstellung der Dateirechte verwendet. Die interne Speicherung der Dateirechte in Unix erfolgt sicherlich nicht in der Oktal oder Symbolischen Notation. Insofern hat die Besprechung der Notationen dort auch nichts zu suchen. Die Notationen sind das Feld der Befehle und Programme zur Verwaltung der Dateirechte.
Auch ist die symbolische Kurznotation nicht das Feld von Chmod alleine. Diverse Programme nutzen die Notation für die darstellung der Dateirechte (z.B. ls) --Arcy 15:41, 28. Dez. 2007 (CET)

Zu den Programmen zur Bearbeitung von Dateirechten: chmod(1) ist sicherlich ein Unikat in Hinsicht auf seine Benutzung. In der Tat fällt mir kein Konsolenprogramm mit den gleichen Kompetenzen ein. Allerdings betrifft das Thema "Unix-Dateirechte" sowie die in diesem Artikel beschriebenen Dinge viele andere Programme und Wiki-Artikel hier. Das Argument ist in Hinblick auf die Diskussionen weiter oben auf dieser Seite bereits hinreichend belegt und deines wiederlegt.

Zu der Notation: Selbstverständlich werden die Unix-Rechte in einem bzw. zwei Bytes gespeichert. Allerdings wird die symbolische Notation/oktalnotation von quasi allen anderen Unix-Programmen genutzt, z.B. chmod(2), stat, ls, usw. Daher ist die Besprechung dieser allgemeingültigen Notation unverweigerlich mit den Unix-Dateirechten verwoben, wohingegen die symbolische Kurznotation ausschließlich Bestandteil von chmod(3) ist. Entgegen deiner Aussage verwendet ls nämlich nie diese Kurznotation. Das würde ja auch keinen Sinn machen, da sowas wie "a+x" keine ausreichende Beschreibung der Rechte einer Datei darstellt.

Nach wie vor gilt: chmod ist nur ein Programm unter vielen, was mit den Unix-Dateirechten in Berührung kommt. Vielleicht ist dieser Vergleich besser: usermod(8) ist auch ein "Kernprogramm", mit dem sich die Benutzer eines Unix-Systems verwalten lassen. Trotzdem wirst du mir nicht wiedersprechen, dass es viele andere Programme gibt, die seine Kompetenzen übernehmen können (passwd, useradd, userdel, gpasswd, ...), auch viele grafische. Und zu guter letzt wird jedes Programm, was mit den Kompetenzen der Unix-Benutzerverwaltung in Berührung kommt, auf die gleiche Schnittstelle zurückgreifen. Daher wäre es auch sinnvoll, das Benutzerkonzept in Unix in einem Wikipedia-Artikel abzuhandeln, statt in diesem Artikel usermod. Oder?

Grüße aus Kelkheim, --Benji 17:37, 28. Dez. 2007 (CET)

Symbolische Notation

@Trublu:

Auch wenn an anderer Stelle (viele) Beispiele für chmod zu finden sind, zwar viele auf englisch, erwarte ich auf Wikipedia unter "chmod" eine gerne auch ausführliche Erklärung über eben "chmod" zu finden.

Ich habe mein Beispiel aber gekürzt, um zumindest die symbolische Notation etwas deutlicher darzustellen.

Wenigstens mir geht es so, dass ich Erklärungen am Besten anhand eines Beispiels verstehe.

--Franc 10:15, 16. Nov. 2007 (CET)

Ich sprach von Unix-Dateirechte#Symbolische_Notation, dort gehört das hin. --Trublu ?! 13:06, 18. Nov. 2007 (CET)

Attributsänderungen nur durch Besitzer oder Root

Die Aussage "...Attributsänderungen lassen sich nur von dem Besitzer der Datei oder dem root-Benutzer durchführen" ist m. E. nicht richtig. -- Chmod777 17:30, 29. Aug. 2011 (CEST)

Was soll denn richtig sein, deiner Meinung nach?

Ich zitiere mal aus der Linux-Manpage des entsprechenden Syscalls:

“The effective UID of the calling process must match the owner of the file, or the process must be privileged (Linux: it must have the CAP_FOWNER capability).”

--RokerHRO 13:14, 31. Aug. 2011 (CEST)