hi
wie kann man die rechte normaler user über die console ändern sodass sie mehr können oder gleichviel wie root... gibt es da eine möglichkeit?
hi
wie kann man die rechte normaler user über die console ändern sodass sie mehr können oder gleichviel wie root... gibt es da eine möglichkeit?
Mehr wird ja wohl kaum gehen, root kann ja schon alles auf deinem system ... Darf man fragen, wieso du so ein "grosses" "Sicherheitsrisiko" eingehen willst?
Wenn es um einzelne Programme geht, dann kann dir vielleicht sudo weiterhelfen: Manpages:
man sudo
man sudoers
MfG carnil
Mehr wird ja wohl kaum gehen, root kann ja schon alles auf deinem system ... Darf man fragen, wieso du so ein "grosses" "Sicherheitsrisiko" eingehen willst?
ich will ja auch nicht mehr rechte als root sondern mehr als ein normaler user und weniger als root dafür festlegen
wollte nur wissen ob es eine möglichkeit gibt das zu tun
oder ob man einen zweiten root unter anderem namen anlegen kann... und wie....
ich will ja auch nicht mehr rechte als root sondern mehr als ein normaler user und weniger als root dafür festlegen
wollte nur wissen ob es eine möglichkeit gibt das zu tun
oder ob man einen zweiten root unter anderem namen anlegen kann... und wie....
Die einzige Möglichkeit einen User mehr Rechte zu geben ist ihn in andere Gruppen zuzuweisen! Oder wie willst du sonst seine Rechte vergrößern?
oder ob man einen zweiten root unter anderem namen anlegen kann... und wie....
Ja man kann einen Benutzer mit gleichen Rechten wie root erstellen: Hab das hier
http://www.linuxforen.de/forums/showthread.php?t=119462&highlight=zweiter+root
gefunden.
Ich bleibe aber trotzdem bei meiner Meinung, dass das schon ein bisschen unvorsichtig wäre, ich würde es einfach unverantwortlich finden. Aber es gibt offenbar wirklich "sinnvolle" Anwendungen davon ....
MfG carnil
Ich bleibe aber trotzdem bei meiner Meinung, dass das schon ein bisschen unvorsichtig wäre, ich würde es einfach unverantwortlich finden. Aber es gibt offenbar wirklich "sinnvolle" Anwendungen davon ....
FULL ACK
Hier noch ein lesenswerter Text zu diesem Thema (Quelle: http://www.theparallax.org/dcoul/user2root/):
[ Dieses Posting erscheint wöchentlich. ]
-----------------------------------------------------------------------
Alle Macht dem User
-----------------------------------------------------------------------
Version vom 15.08.2003
Eine der großen Sünden an einem Unix ist das Arbeiten als "User root".
Dies mag zwar gerade für Ein- und Umsteiger verlockend und bequem
sein, ist aber auch ebenso bedenklich wie leichtsinnig und unnötig.
-----------------------------------------------------------------------
Was ist so besonders an Root?
-----------------------------------------------------------------------
Der Root-Account, häufig auch "Superuser" genannt, ist unter
Unix-Systemen ein besonders privilegisierter Pseudo-Account mit der
UID 0 für systemadministrative Aufgaben. Diesem Nutzer ist quasi alles
erlaubt und so gut wie alle Sicherheitsschutzmechanismen des Systems
sind bedeutungslos für ihn. Die Allmächtigkeit des Nutzers root ist
eine der größten Sicherheitsproblematiken eines Unix-Systems. Für das
System ist nicht der Name ("root"), sondern die User ID des Benutzers
ausschlaggebend. Aus diesem Grund verbannt eine Umbenennung des
Root-Accounts oder das Anlegen eines weiteren Nutzers mit der UID 0
auch nicht die potentiellen Gefahren im Umgang mit Root-Rechten.
Der Root-Account wurde nicht als normaler Benutzeraccount für die
gewöhnliche Systembenutzung entworfen. Er ist daher nicht der
persönliche Account des Systemverwalters, sondern dient lediglich
aufgrund seiner Beschaffenheit zur Erledigung bestimmter
systemadministrativer Aufgaben.
Der Root-Account ist ein besonders privilegisierte Pseudo-Account; er
ist kein normaler persöhnlicher Nutzer-Account!
-----------------------------------------------------------------------
Selbstschutz
-----------------------------------------------------------------------
Wer hat nicht schon einmal eine Datei gelöscht die besser nicht
gelöscht worden wäre? Und falls nun jemand "Hier!" schreit - es ist
wohl nur eine Frage der Zeit, bis dies doch einmal passiert. Die
Userrechte schützen z.B. die systemweiten Konfigurationsdateien vor
unberechtigten Userzugriffen, nicht aber vor einem verunglückten
Tastendruck, einem Vertipper als "root". Ein User kann bei einem
sauber aufgesetzten System maximal die Daten seines Homeverzeichnisses
löschen, "root" hingegen neben den eigenen Dateien auch noch die
persönlichen Daten aller anderen User - oder auch die gesamte
System-Installation.
Wer nicht als "root" eingeloggt ist kann nur geringen Schaden
anrichten.
-----------------------------------------------------------------------
Virenschutz
-----------------------------------------------------------------------
Noch gibt es keine ernstzunehmenden Computerviren, die einem Unix
schaden könnten - es müssen eben erst Rootrechte erlangt werden, um
systemweite Manipulationen vornehmen zu können. Ändert sich nun das
Userverhalten und der "User root" werkelt ständig, so haben einfachste
Skripte - wie bereits in Unix-Newsgroups gepostet - ein leichtes
Spiel.
Ebenso dramatisch wie ein Virus kann auch fehlerhafte Software sein -
der Test eines Dateimanagers im Alpha- oder Betastadium mit
Root-Benutzerrechten kann leicht den gesamten Datenbestand kosten.
Programme ohne Rootrechte können keine systemweiten Schäden anrichten.
-----------------------------------------------------------------------
Wann User, wann "root"?
-----------------------------------------------------------------------
Aus genannten Gründen ist es daher langfristig sehr wichtig nicht als
"root" zu arbeiten - hierzu dient der Useraccount, auf dem die
tägliche Arbeit verrichtet wird. Der Rootaccount dient ausschließlich
der Administration des Systems. Selbst ein Systemadministrator loggt
sich bei einer X-Session (grafische Oberfläche) mit seinem
persönlichen Benutzerkonto ein - dieser Zugang wird dann entsprechend
eingerichtet, so dass er sein System von dort aus administrieren kann.
Als "root" ist man nur wenn es wirklich erforderlich ist und so kurz
wie möglich eingeloggt.
-----------------------------------------------------------------------
su
-----------------------------------------------------------------------
An der Eingabeaufforderung (Konsole, xterm etc.) kann mittels "su -"
zu "root" gewechselt werden. Hier kann nun textbasiert als "User root"
gearbeitet werden - ein eventuell verwendetes xterm z. B. "gehört"
aber nach wie vor dem User.
Tipp: Möchte man lediglich schnell einen einzigen Befehl unter
Root-Rechten ausführen lassen, so kann man mit "su -c 'commando'" der
Shell einen solchen Befehl zur Ausführung übergeben.
Beispiel:
| wk@planet:~$ su -c "tail -f /var/log/messages"
| Password:
| [...]
| Sep 15 15:40:03 planet -- MARK --
| [...]
-----------------------------------------------------------------------
Zugriff auf den X-Server
-----------------------------------------------------------------------
Wer nun versucht ein X-Programm zu starten wird bitter enttäuscht
werden, denn auch "root" darf nicht ohne weiteres einen fremden
X-Server als Ausgabemedium missbrauchen - dies muss zuvor der User
gestatten. Die eigenen "Schlüssel" hierzu liegen in der Datei
"~/.Xauthority", und können über "xauth list" eingesehen werden. Will
nun ein anderer User (in diesem Fall "root") auf unseren X-Server
zugreifen, so benötigt er einen passenden Schlüssel: Diesen kann der
User mit dem Befehl "xauth extract schluessel $DISPLAY" in einer Datei
(in diesem Beispiel "schluessel") abspeichern, und "root" mit dem
Befehl "xauth merge schluessel" dauerhaft seiner "~/.Xauthority"
hinzufügen.
Doch noch immer kann kein X-Programm gestartet werden, denn diesem
muss erst noch mitgeteilt werden, welches Display verwendet werden
soll. Hierfür sorgt die Shellvariable "DISPLAY" (vgl. "man X"), die
"root" noch setzen muss (z.B. durch die Eingabe von "DISPLAY=:0.0;
export DISPLAY"). Ein Beispiel, bei dem der Dateimanager "X-Files" mit
Rootrechten in einer User-X-Session genutzt werden soll:
| jo@planet ~> xauth extract xauth_jo $DISPLAY
| jo@planet ~> su -
| Password:
| root@planet:~> xauth merge /home/jo/xauth_jo
| xauth: creating new authority file /root/.Xauthority
| root@planet:~> DISPLAY=:0.0; export DISPLAY
| root@planet:~> X-Files
| Starting X-Files...
Will man diese Einstellungen nicht jedesmal neu vornehmen sondern
automatisch setzen lassen, so bietet sich für die Shellvariable
$DISPLAY des "Users root" die Datei "/root/.bashrc" an (sofern die
Bash verwendet wird). Der Schlüssel selber bleibt für künftige
Sitzungen erhalten.
Da "root" jedoch die Daten des Users lesen kann, ist in diesem Fall
ein auslesen, transportieren und einfügen des Schlüssels nicht
erforderlich - so ist es möglich, statt dem Ex- und Importieren
einfach die gesamte Datei "~/.Xauthority" des Users zu übernehmen.
Beispiel:
| jo@planet ~> su -
| Password:
| root@planet:~> cp /home/jo/.Xauthority /root/
| root@planet:~> DISPLAY=:0.0; export DISPLAY
| root@planet:~> X-Files
| Starting X-Files...
Weniger dramatisch als das Kopieren oder Importieren fremder
Zugangsdaten ist das Setzen der Umgebungsvariablen "XAUTHORITY", die
"root" einfach auf die ".Xauthority" des Users zeigen lassen kann.
Allerdings muss bei dieser Methode die Variable bei jedem Wechsel zum
Rootaccount erneut gesetzt werden (vgl. $DISPLAY):
| jo@planet ~> su -
| Password:
| root@planet:~> XAUTHORITY=/home/jo/.Xauthority; export XAUTHORITY
| root@planet:~> DISPLAY=:0.0; export DISPLAY
| root@planet:~> X-Files
| Starting X-Files...
-----------------------------------------------------------------------
ssh
-----------------------------------------------------------------------
Eine weitere Möglichkeit grafische Programme mit Rootrechten auf dem
Userdisplay erscheinen zu lassen bietet das Programm "ssh" - ein
"remote login program", das bei entsprechender Konfiguration auch
X-Connections unterstützt:
| jo@planet ~> ssh -X root@localhost
| root@localhost's password:
| [ ... ]
| root@planet:~> X-Files
| Starting X-Files...
Eventuell muss hierfür noch in der lokalen ssh-Serverkonfiguration der
Eintrag "X11Forwarding" auf "yes" gesetzt werden.
-----------------------------------------------------------------------
sudo
-----------------------------------------------------------------------
Wem es nun zu umständlich erscheint, sich nach dem Einloggen als User
nochmals als "root" anzumelden, dem hilft das Tool "sudo". Hiermit
kann man beliebige Befehle oder Programme bestimmten Usern zur
Verwendung freigeben. Konfiguriert wird sudo unbedingt mit dem Wrapper
"visudo", der einen per Default mit dem Texteditor "vi" konfrontiert.
Gibt man hier eine Zeile wie
| jo ALL=NOPASSWD:/usr/local/sbin/fetchnews
ein, so erlaubt das dem User "jo" "/usr/local/sbin/fetchnews" ohne
Passworteingabe zu starten - er muss es nur über "sudo
/usr/local/sbin/fetchnews" aufrufen. Für den Start von X-Programmen
gilt aber auch hier das zu "su" beschriebene - "root" muss wissen,
dass ein zuvor freigegebenes Display verwendet werden soll (xauth &
$DISPLAY).
Wer seine Shell freigibt (diese aber bitte nur *mit* Passworteingabe
freigeben), kann mittels sudo komfortabel eine Rootshell herbeirufen,
bei der alle Einstellungen des Users erhalten bleiben. Auch muss - wie
bei ssh - kein Zugriff auf den X-Server mehr konfiguriert werden.
Hierzu dient bei sudo die Option "-s" ("sudo -s"):
| jo@planet ~> sudo -s
| [ ... ]
| password:
| root@planet ~> X-Files
| Starting X-Files...
-----------------------------------------------------------------------
super
-----------------------------------------------------------------------
Ähnlich wie "sudo" ist das Tool "super": Findet sich in dessen
Konfigurationsdatei "/etc/super.tab" eine Zeile wie
| fnews /usr/local/sbin/fetchnews jo,joe
so können die User "jo" und "joe" das Programm "fetchnews" ohne
Passworteingabe starten - aufzurufen über "super fnews" (vgl. "man 5
super"). Ein alleiniger Aufruf von "super" listet dem User alle ihm
über "super" genehmigten Programme auf.
Und wem "super Programmname" bzw. "sudo Programmname" noch immer zu
umständlich ist, der legt sich z.B. ein Alias "fetchnews" für "sudo
fetchnews" bzw. "super fnews" an.
-----------------------------------------------------------------------
Eintrag ins Startmenü
-----------------------------------------------------------------------
Bislang sind mehrere Eingaben in einer Shell notwendig, um ein
grafisches Programm mit Rootrechten auf dem Userdesktop zu platzieren
- zu viel für einen Menüeintrag. Aber auch hier kann man sich leicht
helfen: Man kann einen kleinen Wrapper schreiben, in dem vor dem
eigentlichen Programmstart sowohl $XAUTHORITY als auch $DISPLAY
gesetzt werden - gibt man dieses Skript nun über "super" (oder "sudo")
zur Verwendung ohne Passwortabfrage frei, so geht das mit einem
einfachen Befehl. Beispiel für einen solchen Wrapper:
| #!/bin/sh
| XAUTHORITY=/home/username/.Xauthority; export XAUTHORITY
| DISPLAY=:0.0; export DISPLAY
| programm
Ein solches Skript abgespeichert unter
| -rwxr-x--- root root /usr/local/sbin/dateiname
und aufgerufen über "sudo /usr/local/sbin/dateiname" startet das
gewünschte Programm mit Rootrechten und ohne Passwortabfrage auf dem
Userdesktop. Und da spätestens jetzt hinsichtlich Bedienung und
Komfort kein Unterschied mehr zwischen User und "root" besteht - warum
weiterhin noch die Risiken des Rootaccounts in Kauf nehmen?
-----------------------------------------------------------------------
Frontends, Wrapper und Tools
-----------------------------------------------------------------------
Mit "kdesu" (KDE-Tool), "xsu" und "GKsu" (GTK/GNOME-Anwendung)
existieren einfache (grafische) Tools, die neben dem Userwechsel
auch den Zugriff auf den X-Server regeln. Damit kann man mit seinem
normalen Systembenutzer-Account ganz bequem eine bestimmte Applikation
mit Root-Rechten unter X starten:
| wk@planet ~> kdesu -c /usr/bin/ethereal
Auch ist es mit einem kleinen Shellscript möglich, einen Wrapper um
"su" zu schreiben, der den Zugriff auf den X-Server regelt. Beispiel:
| #!/bin/sh
| if [ $# -lt 2 ]
| then echo "usage: `basename $0` clientuser command" >&2
| exit 2
| fi
| CLIENTUSER="$1"; shift
| exec su - "$CLIENTUSER" -c "xauth add `xauth list \"$DISPLAY\"`; \
| exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*'"
Ein weiteres Tool mit gleicher Funktionalität ist das von der
SuSE-Distribution bekannte Tool "sux", das im WWW frei unter
http://fgouget.free.fr/sux/ erhätlich ist.
-----------------------------------------------------------------------
Weitere Informationen
-----------------------------------------------------------------------
Zum Thema Sicherheit mit Hinweisen auf den Umgang mit dem Rootaccount
gibt es ein "Security-HOWTO", welches die lokale Festplatte in den
Tiefen des Verzeichnisses "/usr/share/doc" bereithalten sollte.
Aktuelle Versionen können über folgende Adressen bezogen werden:
o http://scrye.com/~kevin/lsh/
o ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/Security-HOWTO
o ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/Security-Quickstart-HOWTO
Weiterer Artikel zum vernünftigen Umgang mit dem Rootaccount:
o "Root und Sicherheit, Einloggen übers Netz" unter
http://sdb.suse.de/de/sdb/html/perms.html
Wer mehr über den (Fremd-)Zugriff auf den X-Server erfahren möchte,
dem sei das "Remote X Apps mini-HOWTO" empfohlen - dieses ist
ebenfalls Bestandteil von "/usr/share/doc", sowie online unter
folgenden Adressen erhältlich:
o http://www.xs4all.nl/~zweije/xauth.html
o ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/mini/Remote-X-Apps
Dieser Artikel ist mit einigen Ergänzungen im WWW zu finden unter
o http://www.theparallax.org/dcoul/user2root/.
Wolfgang Kaufmann (wk-articles@theparallax.com),
Jo Moskalewski (news@jmos.net)
ChandlerBing
24.05.04, 09:42
Ich vermute mal, dass das was Du vorhast, wunderbar mit sudo bzw. su abzuhandeln ist.
Wozu noch einen zweiten "root"? Gibt es dafür einen cleveren Grund?
danke für die vielen antworten :ugly:
der grund ist einfach zu wissen wie es funzt... mehr nicht!
habe es so versucht: "useradd -G root -p test -u 0 test"
dann kam: "useradd: UID 0 nicht eindeutig"
was hat das jetzt zu bedeuten und wie lautet der korrekte befehl?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.