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

[Kay Martinen]

Am 01.11.24 um 08:40 schrieb Rolf Bensch:

> mehr durch Zufall entdecke ich folgendes in /var/log/messages:
> 
> Oct 27 05:44:46 eis64-3 kernel: ATTACKER..IN=enx525400b7e655 OUT= 
> MAC=52:54:00:b7:e6:55:0c:72:74:fe:2a:23:08:00 SRC=80.64.30.52 
> DST=192.168.0.207 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=18877 DF PROTO=TCP 
> SPT=62506 DPT=25 WINDOW=32120 RES=0x00 SYN URGP=
> 0

80.64.30.52:62506 spricht TCP mit 192.168.0.207:25 was offensichtlich 
ein Versuch ist deinen Mailserver zu erreichen. Mehr kann ich da erst 
mal nicht raus lesen, auch nicht ob das ein Angreifer wäre, ein portscan 
oder sonst was.

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

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.

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


> "Monitoring" meldet um 05:45 "Es steht kein Alarm (mehr) an!". Wird hier 
> irgendwas blockiert und wieder freigegeben? Die Meldung aus dem Kernel 
> wird vermutlich von BFB getriggert. Was läuft hier aus dem Ruder?

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?

Und, kannst du mit 'su' zu dem user wechseln und dann an dem ort die 
gegebene datei/ordner öffnen?

Bye/
   /Kay

-- 
������������ ������ ����������������