Dcopserver ?!

[TrataX]

Hi all, ich habe ein problem mit meinem Arbeitsplatz Rechner.
Wenn ich mich als Root einloggen möchte, kommt folgender Fehler:
"Could not read Network Connection List"
"/root/.DCOPserver_XXX_:0 (XXX steht für den rechnernamen )"
"Bitte stellen sie sicher, das das Programm "dcopserver läuft".
Gesagt getan, ich geh in die textebene, möchte dcopserver starten und dann kommt das
"Aborting. $Display is not set."
Naja ok, aber da ich ja noch einen Netzwerkweitern Account habe auf einem Server im Netzwerk,
habe ich das einloggen dort ma versucht, also das geht, es scheint nur an dem Root benutzer zu liegen,
und KDE is schuld
Also bitte helft mir, das is sehr wichtig
thx

[Jorge]

KDE als root ist böse [TM].

[TrataX]

aber reinkommen würde ich schon ganz gerne *g*
Wie kann ich dann über Textebene einen neuen Benutzer adden ?!
Kannst mir das sagen ?
P.s ich würde natürlich immer noch gerne wissen warum das mit dem DCOP net funzt.
thx

[Jorge]

useradd -g users -s /bin/bash -c Kommentar -m -k /etc/skel -p PASSWORT TrataX

man useradd

[TrataX]

dange dange
bin grad auf der suche nach dem Prob und bin auf der KDE darüber gestolpert, wenn man Probs mit dem
DCOPServer hat das man QT (mindestens) 2.2.1 installieren soll, hmm.
Muss ich gleich ma ausprobieren, aber ich lass es ma stehen wenn jemand ne andern Lösugn hat

[TrataX]

auch wenns schon n bissl Off Topic is,
jetzt beim Useradd kommt "Cannot create directory /home/XXX
wat sollen dat ?

[Jorge]

Nur als kleine Bettlektüre warum KDE als root = böse:


------------------------------------------------------------------------
Alle Macht dem User
------------------------------------------------------------------------

Version vom 20.07.2002

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.


------------------------------------------------------------------------
Selbstschutz
------------------------------------------------------------------------

Wer hat nicht 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 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 als "root" 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. Selbst ein Systemadministrator loggt sich bei einer
X-Session (grafische Oberfläche) als User ein - dieser Zugang wird dann
entsprechend eingerichtet, so dass er sein System von dort aus
administrieren kann.

Als "root" ist man nur so kurz wie möglich eingeloggt.


------------------------------------------------------------------------
su
------------------------------------------------------------------------

An der Eingabeaufforderung (Konsole oder xterm) kann mittels "su -" zu
"root" gewechselt werden. Hier kann nun textbasiert als "User root"
gelöscht, verschoben, editiert etc. werden - ein eventuell verwendetes
xterm gehört aber nach wie vor dem User.


------------------------------------------------------------------------
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 ist, 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) und "xsu" (GTK/GNOME-Anwendung) existieren
grafische Tools, die neben dem Userwechsel auch den Zugriff auf den
X-Server regeln.

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...Security-HOWTO

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 unter folgenden Adressen
erhältlich:


o http://www.xs4all.nl/~zweije/xauth.html
o ftp://sunsite.unc.edu/pub/Linux/docs.../Remote-X-Apps

Dieser Artikel ist mit kleinen Ergänzungen im WWW zu finden unter
http://www.jmos.net/user2root/.

Jo Moskalewski - news@jmos.net

[Jorge]

Original geschrieben von TrataX
auch wenns schon n bissl Off Topic is, jetzt beim Useradd kommt "Cannot create directory /home/XXX wat sollen dat ?

Lass mich raten, Du hast versucht den Befehl als normaler User abzusetzen. Mach den mal als root.

[TrataX]

ich hab mich als root eingeloggt ( per shell )

[Jorge]

Was sagt ein "ll -d /home"?