pathdiscover vorgestellt

Posted on 7. Dezember 2017 by marius

Als Admin kennt man das, irgendein Programm will auf eine Datei zugreifen und es geht nicht. Da kommt pathdiscover ins Spiel. Das kleine Linuxtool aus Cyborgs Github-Repository macht Schluß mit dem ewigen Suchen. Es zeigt alle Pfadsegmente mit allen Rechten in einem Schritt an.

Die Ausgabe

Die Ausgabe wird am besten als vorformatierter Text angezeigt, kann sein, daß Ihr da jetzt mal etwas scrollen müßt:

# pathdiscover /home/wordpress/jetpack/

'/home/wordpress/jetpack/' translates to '/opt/root/home/wordpress/jetpack'

 4096 Bytes wordpress/wordpress drwxr-xr-x : jetpack   ( directory )
 4096 Bytes wordpress/services  drwxr-x--- : wordpress ( directory )
 4096 Bytes root/root           drwxr-xr-x : home      ( directory )
 4096 Bytes root/root           drwxr-xr-x : root      ( directory )
 4096 Bytes root/root           drwxr-xr-x : opt       ( directory )

Die Ausgabe kann man mit diversen Optionen anpassen, z.b. auch so, daß alle atime,ctime und mtime Zeitstempel angezeigt werden:

# pathdiscover -d /home/wordpress/jetpack/

'/home/wordpress/jetpack/' translates to '/opt/root/home/wordpress/jetpack'

 4096 Bytes (2013-10-29 15:24:51 | 2013-09-19 17:54:54 | 2017-12-06 06:30:20) wordpress/wordpress drwxr-xr-x : jetpack ( directory )
 4096 Bytes (2017-11-20 16:38:07 | 2017-11-20 16:38:07 | 2017-12-06 06:30:08) wordpress/services drwxr-x--- : wordpress ( directory )
 4096 Bytes (2017-11-09 10:34:50 | 2017-11-09 10:34:50 | 2017-12-06 03:58:54) root/root drwxr-xr-x : home ( directory )
 4096 Bytes (2017-09-01 22:09:15 | 2015-02-10 15:27:53 | 2017-12-05 22:45:02) root/root drwxr-xr-x : root ( directory )
 4096 Bytes (2017-09-01 22:16:29 | 2017-09-01 22:16:29 | 2017-12-06 03:58:39) root/root drwxr-xr-x : opt ( directory )

Die Optionen

Die Hilfe gibt folgende Programmoptionen aus :

pathdiscover [-a] [-d] [-h] [-n] [-V] <filename>

Die Optionen im Einzelnen …

-V gibt die Versionsnummer aus.
-n –names schaltet die Übersetzung von UID in Namen ab.
-N –numbers zeigt die Größe der Datei und Ordner in Bytes an, statt in „Größen“
-a –alternative zeigt den kompletten Pfad zu dem Segment an, statt nur den Segmentnamen
-d –full-time fügt atime, ctime und mtime Ausgaben hinzu.
-NC versucht erst gar nicht die Ausgabe zu formatieren, was z.b. den Einsatz von AWK und SED leichter macht.

Selbst kompilieren leicht gemacht

Da es sich im GITHUB um den rohen C-Sourcecode handelt, muß man das Programm selbst kompilieren, falls es nicht schon in einer Distribution enthalten ist. Stand „Heute“ wird das nicht der Fall sein 😉

Im Gegensatz zu manch anderem Tool, ist das kompilieren, eine einfache Sache:

gcc pathdiscover.c -o pathdiscover

Das war es dann auch schon. Jetzt kann man das Programm z.b. nach /usr/bin/ verschieben und so allen Benutzern zur Verfügung stellen. Kann aber sein, daß es in einigen Monaten und Jahren, wenn sich die Systemumgebung geändert hat, man neu kompiliert werden muß.

Wann braucht man das Programm ?

Das Einsatzgebiet liegt hauptsächlich bei Admins, die sich z.b. fragen, wieso eine Datei von Serverdienst X nicht erreicht werden kann. Meistens sind da die Besitzerrechte der Ordner und Dateien im Weg, weil man z.b. vergessen hat, den Besitzer der Datei zu ändern oder globale Leserechte vergessen hat.

Mit dem Programm bekommt man alles auf einmal übersichtlich angezeigt, so daß es recht einfach wird, solche Probleme zu beheben. Man sieht auch gleich, ob Sym-LInks im Spiel sind, die z.b. von Proftp und Apache nicht immer akzeptiert werden. Kurzum, ein sehr praktischer Befehl.

Cinnamon – Das fehlende Icon

Posted on 5. Dezember 2017 by marius

Problem:

Nach dem Update auf Fedora 26 zeigte die Schnellstartleiste ein leeres Iconfeld:

Schnell stellte sich heraus, daß es sich dabei um die NVIDIA-Settings handelte. Beim eingestellten ICON-Theme gnome :

gibt es nun aber gar kein Icon dafür, weswegen der Platz leer bleibt.

Alle Versuche, das durch direktes Zuweisen in der Desktop Datei unter /usr/share/applications zubeheben, schlugen fehl.
Die Desktopdatei wurde immer wieder auf die Defaulteinstellungen „Icon=nvidia-settings“ zurückgesetzt.

Da wird wohl rohe Kraft nötig sein, um das System vom Gegenteil zu überzeugen! 😀

Die Lösung

Das läßt sich schnell beheben, wenn man einen Theme hat, so wie MINT-Y, der ein Icon dafür bereitstellt :

cp /usr/share/icons/Mint-Y/apps/256/nvidia-* /usr/share/icons/gnome/256×256/apps/

Dann noch schnell das Theme Cache erstellen :

gtk-update-icon-cache –force /usr/share/icons/gnome/

Ab sofort ist da wieder ein Icon, wo es hingehört. Dies muß man als Rootuser machen :

Exim – Wie man TLS erzwingt II

Posted on 4. Dezember 2017 by marius

Im letzten Beitrag Exim – Wie man TLS erzwingt war das Blockieren von ausgehenden Verbindungen ohne TLS Thema. Heute befassen wir uns mit dem Gegenteil : Wie verhindern wir, daß wir eine Email bekommen, die unsicher übertragen wurde?

Exim ’s Access Control Lists

Exim als Mailserver erlaubt es uns, in jede Phase der Übertragung von Emails per SMTP einzugreifen und Emails aufgrund von Mustern und Bedingungen abzulehnen. Die ACL genannten Bedingungsketten sind universell einsetzbar, hier ein Beispiel:

acl_check_helo:

drop condition = ${if eq{$sender_helo_name}{ylmf-pc} {1}}
     message = Your a naugthy boy

accept

Die Helo-ACL prüft ob, sich der anfragende Mailserver mit einem bestimmten Namenskürzel meldet, hier „ylmf-pc„. Das ist so ziemlich todsicher ein Bot aus einem asiatischen Netzwerk. Zur Erklärung :

drop ist das Ziel der Aktion, wenn die condition greift. Hier der Vergleich (if eq) von dem was der „Client“ gesendet hat und dem ylmf-pc Text. Übersetzt heißt das : if ( „sender_helo_name“ == „ylmf-pc“ ) { log.message = „Your a naugthy boy“; message.drop(); }

So sieht das dann im SMTP aus :

220 irgendeinserver.de ESMTP Exim 4.89 Sun, 03 Dec 2017 14:33:48 +0100
HELO ylmf-pc
550 Your a naugthy boy

Ansonsten akzeptiere ( accept ) die Email. Natürlich könnte man hier auch schon DNS IP Blacklisten eintragen, oder andere Abfragen, die keinen Empfänger / Sender benötigen. Die meisten ACls werden aber genau bei der Sender- und Empfängerprüfung eingesetzt. Genau das werden wir in der ACL acl_check_rcpt tun.

Zum Glück sind die nötigen Anweisungen extrem übersichtlich :

acl_check_rcpt:
 ...
 deny condition = ${if eq{$tls_cipher}{}{1}{0}}
      message   = Sender did not use TLS secured connection.

Meint:

If ( tls_cipher == „“ ) { log.message = „Sender did not use TLS secured connection. „; message.deny() }

Das war es schon. Damit kommen nur noch Emails weiter, die über eine TLS gesicherte Verbindung gesendet werden. Ob das Spam ist oder nicht, muß man natürlich trotzdem prüfen, wenn die Mail erst einmal übertragen wurde.

Analyse

Da erst einmal nur der Empfänger in der SMTP Phase genannt wurde, ist der Inhalt der Email noch aus dem sendenen Server, denn der wird erst mit dem DATA Block übertragen. In die HELO ACL kann man das nicht einbauen, da SMTP verlangt, daß ein netter Server erstmal HELO oder EHLO sagt, bevor er weiter macht.

Die übliche SMTP-Befehlsreihenfolge dürfte daher :

HELO
STARTTLS
MAIL FROM:
RCPT TO:
DATA

sein. Man kann es natürlich auch bereits in der mail_from ACL machen, ob das einen großen Unterschied machen wird, ist fraglich.

Marius Welt

Category Archives: Fedora