Andreas Pakulat <[EMAIL PROTECTED]> writes:
>On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote:
>> Andreas Pakulat <[EMAIL PROTECTED]> writes:
>>
>> >Nein, es gibt keine Login-Shell wenn man sich grafisch einloggt.
>>
>> Verstehe ich Dich richtig, dass beim grafischen login ~/.xsession (oder
>> �quivalentes) gestartet wird, ohne dass jemals unter der Kennung des
>> angemeldeten Benutzers ein login shell gelaufen ist?
>>
>> Oder willst den zitierten Satz nur im Sinne von "die Shells in KDE's
>> konsole sind keine login shells" verstanden wissen?
>
>Da fragst du den falschen, so gut kenne ich mich da nicht aus. Aber
>die KDE-Prozesse sind alle Kinder von init und nicht (wie bei dem
>startx-Verfahren) des X11-Servers (IIRC). Die Shells in KDE (*term,
>konsole...) sind alle nicht-login-shells und kriegen offensichtlich
>auch keine Einstellungen aus irgendeiner Login-Shell vererbt... Ich
>denke mit obigem ist das eventuell erklaerbar (wer wessen Kind ist)...
>
>> Den ersten Fall f�nde ich ein bug report wert, der zweite Fall ist v�llig
>> in Ordnung.
>Wieso?
Warum ich den ersten Fall f�r eines bug reports wert halte:
DIE traditionelle Methode, bei der ein Benutzer seinen Zugang
konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login
shells beim Start einlesen. Der Sicherheit am zutr�glichsten ist es,
wenn des Benutzers sicherheitsrelevante Eintragungen, wie etwa umask,
Umgebungsvariablen, u.a., von jedem Zugang (egal, ob login am
Nur-Text-Terminal, kde, gnome, su, slogin, ...) zum System beachtet
werden. Sonst vergisst er garantiert irgendwann, verschiedene
Konfigurationsdateien synchron zu halten, mit der Folge, dass irgendein
Zugang, etwa xdm, gdm, kdm, su, login, slogin noch ein Sicherheitsloch
hat, das der Benutzer bei den �brigen Zug�ngen bereits gestopft hat.
Weil es nun aber den textorientierten Zugang "login am Nur-Text-Terminal"
immer noch gibt und dabei die einzigen Konfigurationsdateien die eines login
shells (etwa ~/.profile) sind, muss dort also eine ordentliche
Konfiguration vorgenommen werden. Aus den oben genannten Gr�nden sollten
kde, gnome, xdm, su, slogin, ... diese Konfigurationsdatei ebenfalls
verwenden, indem sie ein login shell starten.
Warum ich den zweiten Fall f�r in Ordnung halte:
Ein login shell ist traditionell eines, an dem eine interaktive Sitzung
h�ngt und mit dem sie steht und f�llt. Daher w�rde ich in die
Konfigurationsdatei eines login shells (etwa ~/.profile, ~/.login,
~/.bash_profile) solche Kommandos stellen, die die Umgebung nicht nur f�r
dieses shell, sondern f�r alle daraus gestarteten Prozesse beeinflusst,
beispielsweise umask-, ulimits-, und solche Kommandos, die die
Umgebungsvariablen beeinflussen.
Diese Kommandos sollen aber nur ein einziges Mal innerhalb einer Sitzung
ausgef�hrt werden, nicht jedes Mal aufs Neue, wenn ich z.B. in kde ein
neues konsole-Fenster �ffne. Daher ist der zweite Fall f�r mich in
Ordnung.
Ein Beispiel soll das verdeutlichen: Angenommen, ich m�chte unterhalb
meines HOME-Verzeichnisses ein Verzeichnis anlegen, in das ich
selbstgeschriebene Programme stelle. Diese Programme sollen nat�rlich
vom shell gefunden werden. Also stelle ich das Verzeichnis in den PATH.
F�r das bourne shell nehme ich die Datei ~/.profile und schreibe hinein:
export PATH
PATH="$HOME"/bin:"${PATH:-/usr/local/bin:/usr/bin:/bin}"
Wenn jetzt ein konsole ein login shell starten w�rde, k�me bei jedem
shell, das in einem konsole l�uft, an den PATH vorne "$HOME"/bin/: dran.
Wenn ich also aus einem konsole ein weiteres starte, indem ich darin
konsole &
eintippe, w�re "$HOME"/bin dann schon zweimal im PATH u.s.f., was keine
gute Idee ist.
Daher w�rde ich innerhalb einer interaktiven Sitzung nur EIN shell als
login shell laufen lassen. Und zwar m�sste es das shell sein, von dem
alle meine Prozesse, die ich in der Sitzung starte, die Umgebung
erhalten.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <[EMAIL PROTECTED]>, (Helmut Waitzmann) [EMAIL PROTECTED]
