[Eisfair] [E64] exim: "systemd: Failed to resolve symlink /usr/local/share/systemd/user, ignoring: Permission denied"

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

> Was mir nur "leider" unerfreulich auffällt ist, das...
> 
>> Oct 27 05:45:55 eis64-3 su[4714]: (to exim) root on none
>> Oct 27 05:45:55 eis64-3 (systemd): pam_unix(systemd-user:session):
>> session opened for user exim(uid=488) by (uid=0)
> 
> ... sich in den folgenden dutzenden Zeilen systemd scheinbar mehr mit
> sich selbst beschäftigt oder kundtut welche heldentaten (stopped,
> started, closed user, slice, session target, blah-blah) er da vollbringt.

Das ist normal bei systemd. Mach mal in einer Root-Konsole

tail -f /var/log/messages

und logge dich nun an einer ssh-Konsole als irgendein-User ein und dann 
spult systemd hier auch alles ab.

Du hast in systemd auch als User die Möglichkeit services und Co. 
einzurichten, also macht systemd beim Einloggen nicht anderes, als die 
Sitzung vorzubereiten.

> Das mag an mir liegen das ich mich einfach nicht damit anfreunden kann
> das; und warum oder wozu; es ein main user target gibt u.s.w. aber mein
> Eindruck ist der einer geringeren Informativen Dichte zugunsten
> eigentlich nutzloser geschwätzigkeit - des init.

Mir ist ehrliche gesagt, Geschwätzigkeit lieber. Die paar Byte stören im Log 
doch nicht, wann schaut man da schon rein.

Wenn es ein Problem gibt, ist man froh möglichst viele Infos zu haben.

> So weit ich dunkel an früher logs erinnere war dort mehr abwechslung
> drin und es lief serieller. Will sagen; man konnte es besser von oben
> nach unten lesen und dem grund leichter auf die spur kommen. Einfach
> weil der grund sich oft schon zeilen vorher mit einem eintrag ankündigte
> und die Folgen in weiteren logzeilen festgehalten wurden.

SysV-Init arbeitet seriell, systemd möglichst parallel.

> Das war's schon mit der allgemeinen Kritik. Nur noch die Frage: Hast du
> evtl. den loglevel irgendwo hoch gedreht?

Die systemd-"Einlogmeldungen" kommen, ohne selbst irgendeinen Debug- oder 
Log-Level setzen zu müssen.

> Ich erkenne neben der "Attacker" meldung des Kernels (BFB?) nur noch die
> permission denied meldungen als wichtigeres Problem dem du mal auf die
> Spur kommen müßtest.
> 
> Sprich: welchen user und rechte hat der aufrufende Prozess und welche
> user und Rechte bestehen auf dem Weg zum inkriminierten Pfad?

Den Pfad gibt es üblicherweise auf eis nicht, womit ich mich frage, wieso 
systemd da überhaupt rein will. Auch bei Rolf gibt es die nicht, aber 
systemd möchte die lesen.

Also ist auf Rolfs System der systemd durch ein Konfigurationseinstellung 
aufgefordert, auch in /usr/local/systemd/... zu schauen, was zunächst mal 
nichts böses darstellt. Üblicherweise dient ja der Pfad /usr/local dazu, 
Programme abseits des Distributionsmanagers oder Eigenkompilate zu 
installieren.

Was mich nun auf die Idee bringt, ob das auch bei einem normalen Userlogin 
passiert.

@Rolf:

Mach doch mal das, was ich am Anfang der Mail vorgeschlagen habe.

Und weitere Idee:

Hast du mal was auf deinem eis aus einer Source selbst kompiliert und 
installiert?

Das könnte zu dem Effekt geführt habe.

-- 
Gruß Marcus
[eisfair-Team]