Benutzer Berechtigung geben Dateien eines anderen Benutzer zu löschen

[inception]

Hallo,

wie kann ich einem Benutzer die Berechtigung geben die von einem anderen Benztzer erstellten Dateien zu löschen? Bzw. genau eine Datei wäre sowas auch möglich?

Mfg,

Daniel

[breakthewall]

Natürlich geht das. Allerdings nicht mit dem regulären Rechtekonzept. Hier muss man mit ACLs arbeiten, um erweiterte Rechte für Nutzer zu etablieren. Von Haus aus werden ACLs auch von zahlreichen Dateisystemen unterstützt. Über das Programm setfacl kannst individuelle ACLs setzen, und via getfacl entsprechend abrufen. Und mittels Dateimanagern wie Dolphin, können ACLs auch auf grafische Weise gesetzt werden.

[MSfree]

Natürlich geht das. Allerdings nicht mit dem regulären Rechtekonzept.

Doch.

Hier muss man mit ACLs arbeiten

Nein, es geht auch mit normalen Benutzer- und Gruppenrechten.

Man kann z.B. alle Nutzer in die selbe Gruppe stecken und Verzeichnisse, in denen jeder löschen und Dateien anlegen können soll, mit chgrp in diese Gruppe setzen und mit chmod g+rwx Gruppenberechtigungen verpassen.

Danach darf jeder, der Mitglied in der Gruppe ist, auch Dateien in dem Unterverezichnis löschen, selbst, wenn sie anderen gehören und read-only sind.

Das schließt ACL übrigens nicht aus, das kann man noch oben drauf setzen

[breakthewall]

Aus gutem Grund wurde dieses umständliche Gruppen-Gefrickel nicht erwähnt. Das ist für mich nicht mehr zeitgemäß und furchtbar unflexibel. Daher wird das erst garnicht vorgeschlagen, wenn solche Probleme durch ACLs effizienter gelöst werden können. Sicher geht es auch anders, nur warum umständlich wenn es auch einfach geht?

[inception]

die Datei ist im tmp Ordner gehört der gruppe "sb" und der Besitzer ist "Arvl". Mit dem user sb kann ich die Datei aber nicht löschen.

[Meillo]

die Datei ist im tmp Ordner gehört der gruppe "sb" und der Besitzer ist "Arvl". Mit dem user sb kann ich die Datei aber nicht löschen.

Das /tmp-Verzeichnis hat ueblicherweise das Sticky-Bit gesetzt, was dafuer sorgt, dass man, trotz Schreibrechten fuer alle, nur seine eigenen Dateien loeschen kann. Daran liegt das.

[inception]

kann man das umgehen?

[Meillo]

Beschreibe doch erstmal dein konkretes Szenario. Vielleicht gibt es eine viel bessere Loesung auf einem anderen Weg.

[inception]

Ich habe vor mehrere Sinusbots laufen zu lassen. Bevor ich einen Weiteren Bot starte muss eine .Sinusbot.lock und X40 datei gelöscht werden. Diese Befinden sich im tmp Ordner. Den einen Bot habe ich mit dem user "sb" gestartet den anderen wollte ich mit dem user "arvlsb" starten. Nun wollte ich in das startscript reinschreiben das diese Datei gelöscht wird will dieser aber sehr ungerne Root rechte geben.

[breakthewall]

Ich habe vor mehrere Sinusbots laufen zu lassen. Bevor ich einen Weiteren Bot starte muss eine .Sinusbot.lock und X40 datei gelöscht werden. Diese Befinden sich im tmp Ordner.

Du könntest zwar die Rechte von /tmp ändern, aber das wäre nicht empfehlenswert. Und wie bereits gelesen hast, hat das Sticky-Bit schon seine Daseinsberechtigung. Mal davon abgesehen, dass keine Dateien in /tmp ablegen musst, und alternativ ebenso bspw. /dev/shm dafür verwenden kannst. Das wird seitens Systemd zwar auch mittels 1777 Rechten gemountet, aber kann im Vergleich zu /tmp problemlos geändert werden.

Es fehlt noch eine Erklärung zur Datei X40, bzw. für was diese gut ist und was sie beinhaltet. Zumindest wäre die Sinusbot.lock mittels flock ersetzbar, zumal Datei-Locks recht problematisch sind, insbesondere bei Abstürzen bzw. unvorhergesehenen Programmabläufen.

[inception]

beides leere dateien

[inception]

Die dateien werden beim start von dem sinusbot automatisch geschrieben heißt also das ich den speicherort nicht bestimmen kann. Die verschiedenen bots auf einem user laufen lassen geht leider auch nicht. Bzw das starten und die Installation. Sobald der bit dann mal läuft kann ich die gruppe und den besitzer problemlos ändern.

[Meillo]

Was ist denn ein Sinusbot?

Schon doof, dass die Implementierung einen hardgecodeten Dateinamen in /tmp verwendet. Das Betreiben mehrerer Instanzen auf einem Rechner scheint nicht vorgesehen zu sein, obwohl es sinnvolle Usecases dafuer zu geben scheint. Schlechtes Design.

Noch eine andere Idee: Vielleicht ist /tmp ja nicht hardcoded, sondern es wird zuerst (wie es sein sollte) die Umgebungsvariable TMPDIR ausgewertet -- scheint mir nach obiger Erfahrung zwar unwahrscheinlich zu sein, aber die Hoffnung stirbt zuletzt. Versuche also mal etwas in der Art:

Code: Alles auswählen

mkdir /tmp/a
chmod 777 /tmp/a
TMPDIR=/tmp/a sinusbot

Damit sollten die temporaeren Dateien in /tmp/a landen ... wenn sich die Programmierer an die Konventionen gehalten haben.

[inception]

sobald ich versuche eine datei des anderen benutzers zu löschen kommt: "rm: remove write-protected regular empty file 'test'?" woran liegt das? Scheint so alsob die rechte nicht richtig eingestellt sind

[inception]

Kann man nicht über Sudo dem Benutzer arvlsb die rechte für sb geben? Kenne mich da leider nicht so ganz aus . Wobei das dann wieder Sicherheitslücken geben würde oder nicht?

[Meillo]

sobald ich versuche eine datei des anderen benutzers zu löschen kommt: "rm: remove write-protected regular empty file 'test'?" woran liegt das?

Na, soweit ist doch alles in Ordnung. Du hast keine Schreibrecht fuer die Datei aber welche fuer das Verzeichnis, darum wirst du gefragt, ob du sie wirklich loeschen willst. (Du kannst sie loeschen, aber die Loeschaktion ist evtl. unplausibel, darum die Frage.)

Wenn du nicht loeschen kannst, dann kommt:

Code: Alles auswählen

rm: cannot remove `/tmp/foo': Operation not permitted

(Der Grund, warum man in /tmp keine fremden Dateien loeschen darf, obwohl man Schreibrechte auf das Verzeichnis hat, ist das Sticky-Bit.)

[Meillo]

Ich habe mal im Web nach dem Sinusbot gesucht: Das ist so Teamspeak-Zeugs ...

Wenn man https://wiki.sinusbot.com/en:guides:ins ... tartscript anschaut, dann wird schnell klar, dass das Programm wenig Unix-artig ist und sich folglich nur mit Muehe auf Unix-Art betreiben laesst. Genau an der Stelle haengen wir hier. Das Problem sind nicht Dateiberechtigungen unter Unix, sondern dass die Entwickler des Sinusbots Unix nicht verstanden haben. Wuerden sie ihr Programm so entwickeln wie man das seit Jahrzehnten unter Unix tut, dann gaebe es hier keine Probleme. ich hab wenig Lust ein stimmiges Systemkonzept fuer kaputte Software hinbiegen zu muessen ...

[inception]

ich löse es ganz einfach:

Code: Alles auswählen

#!/bin/sh
SCREEN_NAME="arvlsb"
EXECUTING_USER="arvl"
DIR_NAME="/opt/kunden/arvl"
case "$1" in
start)
	rm /tmp/.sinusbot.lock
	rm /tmp/.X11-unix/X40
	cd ${DIR_NAME}
	sudo -u ${EXECUTING_USER} screen -mdS ${SCREEN_NAME} ${DIR_NAME}/sinusbot -- /usr/bin/Xvfb :1 -screen 0 800x600x16 -ac
	;;
stop)
	sudo -u ${EXECUTING_USER} screen -S ${SCREEN_NAME} -X stuff '\003' > /dev/null 2>&1
	sudo -u ${EXECUTING_USER} screen -S ${SCREEN_NAME} -X stuff '\004' > /dev/null 2>&1
	;;
esac
exit 0

Der bot wird über die rc.local beim start des servers gestartet d.h es sind so oder so root rechte vorhanden. Falls ich den manuell starten sollte würde das auch mit root rechten geschehen.

[inception]

Meillo kennst du dich mit der rc.local Datei aus da gibt es nähmlich noch eine kleinigkeit

[Meillo]

Der bot wird über die rc.local beim start des servers gestartet d.h es sind so oder so root rechte vorhanden. Falls ich den manuell starten sollte würde das auch mit root rechten geschehen.

Na, wenn er nun eh mit root-Rechten laeuft ...

Was ich inhaltlich noch nicht verstehe: Warum legt er diese Lock-Datei an? Die braucht man doch nur, wenn man verhindern will, das ein zweiter Bot parallel laeuft. Das scheint also nicht passieren zu duerfen -- warum? Genau das willst du aber tun: zwei Bots parallel zu betreiben. Wozu gibt's diese Lock-Datei? Die ja einfach weggeloescht wird, sowohl in deinem SystemV-Init-Script als auch in dem verlinkten Systemd-Unitfile. Die kann ja keine Wichtigkeit haben, wenn man sie einfach loeschen kann ... obwohl sie, laut Namen, eine Lock-Datei sein soll. Das macht fuer mich noch keinen rechten Sinn.


Um nochmal konstruktiver beizutragen: Mir ist eingefallen, dass du den Bot auch in einer Chroot betreiben koenntest. Dann hat er naemlich sein eigenes /tmp-Verzeichnis.

... ich frage mich nun aber doch, ob das ueberhaupt geht, oder ob die irgendwie kollidieren wuerden, weil sonst braeuchte es diese Lock-Datei ja nicht ...



rc.local ist ein Shellscript, das am Ende des Bootvorgangs als root ausgefuehrt wird. Wenn du Fragen dazu hast, frage. Irgendjemand hier wird dir bestimmt helfen koennen.

[inception]

Der bot läuft nicht mit root rechten um das startscript zu benutzen braucht man rootrechte. Der Bot läuft wie gewollt über einen anderen User. Ich denke es ist nicht gewollt das man mehrere Bots auf einem server laufen lässt da man für mehr Instanzen Normalerweise zahlt. Zur rc.local frage wie kann ich ohne ein weiteres script bewirken das die scripts nacheinander gestartet werden. Sprich Script1(erfolgreich gestartet) dann erst script2 usw.

[Meillo]

Der bot läuft nicht mit root rechten um das startscript zu benutzen braucht man rootrechte. Der Bot läuft wie gewollt über einen anderen User.

Stimmt, hab ich uebersehen.

Zur rc.local frage wie kann ich ohne ein weiteres script bewirken das die scripts nacheinander gestartet werden. Sprich Script1(erfolgreich gestartet) dann erst script2 usw.

Mit `&&' verketten:

Code: Alles auswählen

script1 && script2

[rendegast]

Schon doof, dass die Implementierung einen hardgecodeten Dateinamen in /tmp verwendet. Das Betreiben mehrerer Instanzen auf einem Rechner scheint nicht vorgesehen zu sein, obwohl es sinnvolle Usecases dafuer zu geben scheint. Schlechtes Design.

Das Problem sind nicht Dateiberechtigungen unter Unix, sondern dass die Entwickler des Sinusbots Unix nicht verstanden haben. Wuerden sie ihr Programm so entwickeln wie man das seit Jahrzehnten unter Unix tut, dann gaebe es hier keine Probleme. ich hab wenig Lust ein stimmiges Systemkonzept fuer kaputte Software hinbiegen zu muessen ...

steam legt auch eine solche Datei.log in /tmp/ an.



Lösung wären vielleicht auch Container für die Instanzen des Bot.

[inception]

Miteinander verketten geht nicht es wird ja wie folgt eingetragen:

/home/bsp/script.sh start
/home/bsp1/script.sh start

Dafür müsste ich ein weiteres script anlegen. Vielleicht ist das doch die beste Lösung

[Meillo]

Miteinander verketten geht nicht es wird ja wie folgt eingetragen:

/home/bsp/script.sh start
/home/bsp1/script.sh start

Geht doch ganz wunderbar:

Code: Alles auswählen

/home/bsp/script.sh start && /home/bsp1/script.sh start