Archiv verlassen und diese Seite im Standarddesign anzeigen : User darf keine Platte mounten?
Hallo,
ich setze SuSE 8.2 ein und habe verschiedene User am System angemeldet. Standardmäßig ist die externe Festplatte zur Datensicherung -> umounted.
Wie kann ich nun einem normalen User das Recht geben diese externe Festplatte kurz zu mounten und auch noch das Recht, das Verzeichnis /root zu sichern, ohne dass er su wird? :confused:
Bin für jede Spur dankbar!
Hallo,
Bin für jede Spur dankbar!
nun, dieses Forum hat eine ganz tolle Suchfunktion. :cool:
Gruß
hp_tux
Edit:
P.S.
man sudo
Sorry - ich hatte da etwas überlesen.
Mounten und umounten mit dem Eintrag ...,users, in der fstab.
Beim Verzeichnis root kommt es darauf an, wie die Dateirechte gesetzt sind. Sprich ob er lesen darf oder überhaupt keinen Zugriff hat.
Superschnelle Tipps!
-> hp_tux: su und sudo sind mir bekannt und auch die SUFU hatte ich schon benutzt, hatte aber nichts geholfen ... poste das ganze Problem unten!
-> kleinhirn: die externe Firewire-Festplatte hat keinen Eintrag in der /etc/fstab, da sie standardmäßig nicht gemountet sind.
SO NUN DAS GANZE PROBLEM MIT HINTERGRUNDWISSEN:
Ich habe mir ein bash-Script gebastelt, welches ich nachts auf meinem privaten Server starte (per cron-Job). Sodann wählt sich mein Server SuSE 8.2 per Internet-Verbindung und ssh Proto 2 beim Server im Büro ein und sichert mit rsync die ganze Festplatte des File-Servers, so weit so gut. Bei den Daten handelt es sich z.T. um Verzeichnisse, die nur für User root zugänglich sind. Ferner mounte ich per Script-Befehl meine lokale externe Platte, auf die dann die ganzen Daten gesichert werden. Sodass alle Befehle korrekt verarbeitet werden, melde ich mich per Script beim Büro-Server als User root mit pub-key an. Ich würde das allerdings gerne verbieten und mich per Script als User xyz anmelden, nur dann kann ich ja keine externe Platte mehr mounten, das darf nur User root.
Nun meine Frage: Wie kann ich im Script als angemeldeter User xyz den Befehl su -l absetzen und dann per script das Passwort direkt übergeben, sodass ich danach dann mit su-Rechten die Platte mounten kann?
Darum denke ich, dass ich am besten dem User xyz die Rechte gebe, die Platte zu mounten, das Verzeichnis /root zu sichern und dann die Platte wieder abzumelden. Das muss doch gehen? :ugly:
Bin für jeden Tipp dankbar!
Hallo,
die externe Firewire-Festplatte hat keinen Eintrag in der /etc/fstab, da sie standardmäßig nicht gemountet sind.
hmm, für dieses Problem gibt es doch die Optionen "noauto" und "user" bzw. "users", oder habe ich da jetzt etwas mißverstanden?
Gruß
hp_tux
bin wohl gedanklich auf dem Holzweg, um mein Problem zu lösen :ugly: .
-> hp_tux, ich denke, mit dem letzten Tipp müsste ich ein Stück weiter kommen. Werde mir mal die man mount genau durchlesen. Zunächst mal danke!
Mit ist noch nicht ganz klar, was ich da so alles eintragen muss. Ich will auf keinen Umständen, dass das Filesystem der Firewire-Platte bei einem etwaigen Rechner-Bootvorgang gemountet wird, da meine Firewire/USB-Schnittstelle erst später per hotpluging ins system eingebunden wird. Ist halt ne alte Kiste.
Hallo,
Mein Problem ist, dass ich als normaler User xyz, eingeloggt auf dem externen Sytem per ssh, nicht die Platte mit mount mounten darf, da man dazu root-Rechte benötigt.
oh, sorry, das wußte ich nicht.
Ich habe aber noch eine Idee - ich weiß allerdings nicht, ob das auch praktikabel ist: kannst Du vielleicht den mount-Befehl in ein Skript packen, das suid-root läuft?
Gruß
hp_tux
Was bedeuten denn die Zahlen 1 und 2 ganz am Ende eines Mount-Eintrags in der fstab?
Hallo hp_tux,
habe die externe Firewire-Platte nun in die fstab mit der Option: user,noauto ... eingetragen und es funzt.
Super!!! Kann nun die Platte als User ohne su-Rechte mounten, gewusst wie, lesen bildet doch weiter :D .
Nun werde ich mein script umstellen und kann dann endlich den root-User für die ssh-Verbindung untersagen. Danke für Eure Tipps!
Was bedeuten denn die Zahlen 1 und 2 ganz am Ende eines Mount-Eintrags in der fstab?
man fstab - Ist zu viel zum Kopieren. ;)
Danke für den Tipp, habe ich doch glatt gemacht, man mount bringt noch viel mehr zu Tage. Trotzdem, in beiden manpages habe ich über diese Zahlencodes nichts gefunden?
Noch eine Frage, ich will als User xyz das Verzeichnis /root sicher, bekomme aber vom System keinen Zugriff? :eek: Wie kann ich das ändern bzw. ermöglichen, Leserechte sollten ausreichen! Danke!
Danke für den Tipp, habe ich doch glatt gemacht, man mount bringt noch viel mehr zu Tage. Trotzdem, in beiden manpages habe ich über diese Zahlencodes nichts gefunden?
Noch eine Frage, ich will als User xyz das Verzeichnis /root sicher, bekomme aber vom System keinen Zugriff? :eek: Wie kann ich das ändern bzw. ermöglichen, Leserechte sollten ausreichen! Danke!
Soso, man fstab hat Dir nix zu den beiden Werten gesagt? Komisch, bei mir is das wunderbar beschrieben.
Das fünfte Feld, (fs_freq), wird von dump(8) benutzt um zu entscheiden
welche Dateisysteme gedumpt werden müssen. Ist das fünfte Feld nicht
vorhanden, wird für diesen Wert Null angenommen und dump geht davon
aus, daß das Dateisystem nicht gedumpt werden muß.
Das sechste Feld, (fs_passno), wird von fsck(8) benutzt um die Reihen-
folge, in der die Dateisysteme während des Reboots geprüft werden,
festzulegen. Das root-Dateisystem sollte mit einer fs_passno von 1
versehen sein, andere Dateisysteme mit einer fs_passno von 2. Dateisys-
teme innerhalb eines Laufwerks werden sequentiell geprüft, Dateisysteme
auf verschiedenen Laufwerken jedoch gleichzeitig, um parallel arbeit-
ende Hardware zu unterstützen. Ist das sechste Feld nicht vorhanden
oder Null, wird eine Null zurückgegeben und fsck geht davon aus, daß
das Dateisystem keiner Prüfung bedarf.
Habe testweise die Rechte von "root" auf lesbar für andere gesetzt. Ich kann kopieren. Die kopierten Dateien haben anschliessend natürlich meine Userrechte.
Beim Zielpfad benötigst Du natürlich Schreibrechte.
Super danke:
-> towo2099: sorry, das habe ich bei dem vielen lesen von tipps und howtows und manpages beim Überfliegen übersehen. Ganz klar ist mir das mit dump noch nicht.
->kleinhirn: okay, werde ich gleich mal versuchen. Waren das die Lese-Rechte der Gruppe other? Müsste das nicht auch klappen, wenn ich dem User xyz einfach als weitere Gruppenzugehörigkeit "root" mitgebe? Hat dann der User xyz eignetlich die vollen root-Rechte?
Danke nochmals für Eure Mühe ;)
Einem User rootrechte zu geben, nur um das Verzeichnis root lesen zu können ist doch etwas übertrieben. Leserechte für others reichen volkommen aus. Nur wie oben geschrieben, die Dateien gehören nach dem speichern dem User und nicht mehr root. Aber das ist ja schnell wieder geändert.
Hallo Dieter,
da gebe ich Dir vollkommen Recht, das ist mit Kanonen auf Spatzen geschossen.
Trotzem habe ich noch ein Problem zu lösen, denn ich kann ja nicht jeder Datei bzw. jedem Unterverzeichnis, die beim Lesen angemosert wird, einzeln die Leserechte geben, das ist doch recht mühselig. :confused:
LETZTES PROBLEM hierzu:
Wie ermögliche ich es jetzt noch einem normalen User xyz das geschützte Verzeichnis /root ... etc. zu lesen und zu sichern? Der User xyz hat ja da keine Leserechte!
Kann man das abgefragte Kennwort für su -l zum Einloggen als Superuser in einem Script übergeben?
Danke für jeden Hinweis!
Danke für den Tipp! Bin schon am testen, klappt aber noch nicht ganz, warum?
Zu Hause:
- server SuSE 8.2
- ich start mein script manuell oder per cronjob als user root
Versuch 1
- rsync loggt sich dann per ssh als user xyz im Büro-Server ein
... rsync options "ssh ... blablabla" ...
-> habe keine Rechte Verzeichnis /root des Büro-Servers zu lesen.
Versuch 2
- rsync loggt sich dann per ssh als user xyz im Büro-Server ein
... sudo rsync options "ssh ... blablabla" ...
-> habe trotzdem keine Rechte Verzeichnis /root des Büro-Servers zu lesen.
Muss denn sudo auf dem Büro-Server installiert sein?
Ich starte das script bei mir zu Hause auf dem Server
Im Büro, angebunden übers Internet
- server SuSE 9.0
- Fileserver, dessen Daten nach Hause gesichert werden sollen
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.