Moin,
Dietz Pröpper <dietz@rotfl.franken.de> (Mo 07 Jan 2013 15:30:14 CET):
> Heiko Schlittermann:
> > Dietz Pröpper <dietz@rotfl.franken.de> (Mo 07 Jan 2013 13:58:57 CET):
> > > /etc/environment wird via pam ausgewertet, und funktioniert wie
> > > erwartet. Ob's für Shells so geht wage ich zu bezweifeln, spätestens
> > > wenn /etc/profile ausgeführt wird ist der PATH weg (da in /e/p
> > > explitit gesetzt)
> >
> > Das ist ein guter Punkt. Warum eigentlich ist das so? Vielleicht weil
> > pam_env nicht nach UIDs unterscheiden kann?
>
> Möglicherweise. Wobei es ein no brainer wäre, das ganze in /etc/profile nur
> für uid==0 umzusetzen. Wobei ich mir einbilde, dass der path u.U. auch via
> irgendwelche pam-Magie gesetzt werden kann.
Aber PAM läuft doch eigentlich komplett vor und nach der Sitzung ab, so
daß die /etc/profile alles kaputt macht..
Und die Manpage zu pam_env ist falsch. Man muß offenbar user_readenv=1
eintragen. (Huh, 87 Bugs…, das weckt ja Vertrauen.)
Und pam_env wird auch nicht von allen verwendet. Bei mir nur von
atd cron login openvpnas slim sshd su
Also z.B. nicht von sudo(8).
> Wobei ein kurzer Blick in die Xsessions der $hier installierten Display
> Manager einen neuen Verantwortlichen ergibt - sowohl Xsession von kdm, als
> auch die von gdm3 rufen (u.a.) /etc/profile, damit braucht's hinterher
> keine Loginshell mehr.
Und was machen die /etc/profiles dann, wenn die davon ausgehen, daß es
ein Terminal gibt und zum Beispiel mit dem Nutzer kommunizieren
möchten?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-
Attachment:
signature.asc
Description: Digital signature