I have planned various new seminars for the fall. All seminars listed will take place online and in English. I offer the following seminars:
Linux Basics
OpenLDAP Administration
Samba Administration
The exact contents, prior knowledge, and prerequisites are described in the corresponding announcements.
All seminars listed here will take place online and in English.
Do you have any further questions? Just get in touch with me.

Alle guten Dinge sind drei, deshalb hier der dritte Artikel über die Einrichtung meiner Opencloud-Instanz auf einem Raspberry. Bis zu diesem Zeitpunkt läuft der Dienst mit allen benötigten Containern. Die Festplatte ist eingebunden und kann genutzt werden. Aber was passiert, wenn der Rechner neue gestartet wird? Genau, der Dienst startet noch nicht automatisch. Um den Dienst, mit allen benötigten Container bei jedem Start zu aktivieren und beim Herunterfahren zu deaktivieren, habe ich ein kleines Systemd-Skript geschrieben. Das Skript /etc/systemd/system/owncloud.service

[Unit]
Description=Firewall
After=network.target

[Service]
Type=oneshot
ExecStart=/home/stka/opencloud-start.bash
RemainAfterExit=true
ExecStop=/home/stka/opencloud-stop.bash
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Beim Start wird das skript /home/stka/opencloud-start.bash ausgeführt:

#!/bin/bash
OC_PATH=/opt/opencloud/deployments/examples/opencloud_full
OC_CMD=’docker compose up -d‘
cd $OC_PATH
$OC_CMD

Und beim Stoppen des Dienstes das Skript /home/stka/opencloud-stop.bash:

#!/bin/bash
OC_PATH=/opt/opencloud/deployments/examples/opencloud_full
OC_CMD=’docker compose down‘
cd $OC_PATH
$OC_CMD

Damit ist die Einrichtung von Opencloud soweit abgeschlossen.

Jetzt fehlt dann nur noch eine Erweiterung der Firewall. Leider konnte ich in den Containern nicht so ohne weiteres ermitteln, wo denn die iptables-Regeln abgelegt sind. Aus dem Grund habe ich ein Skript geschrieben, dass die bestehenden Regeln erweitert. Wichtig war es mir, dass ein Angriff auf den ssh-Port dazu führt, dass die IP-Adresse des Angreifers gesperrt wird und das Portscanns erkannt und geblockt werden. Hier das Skript:

# Verwerfe SYN-Pakete
$IPT -A INPUT -p tcp ! –syn -m state –state NEW -j DROP
$IPT -I INPUT -m conntrack –ctstate NEW -p tcp ! –syn -j DROP

# Verwerfe fragmentierte Pakete
$IPT -A INPUT -f -j DROP

# Verwerfe XMAS-Pakete
$IPT -A INPUT -p tcp –tcp-flags ALL ALL -j DROP

# Verwerfe alle NULL-Pakete
$IPT -A INPUT -p tcp –tcp-flags ALL NONE -j DROP

# Verwerfe Spoof-Pakete
for SPOOF in 224.0.0.0/4 240.0.0.0/5 240.0.0.0/5 0.0.0.0/8 239.255.255.0/24 255.255.255.255; do
$IPT -A INPUT -d ${SPOOF} -j DROP
done
for SPOOF in 10.0.0.0/8 169.254.0.0/16 172.16.0.0/12 127.0.0.0/8 192.168.0.0/24 224.0.0.0/4 240.0.0.0/5 0.0.0.0/8 ; do
$IPT -A INPUT -s ${SPOOF} -j DROP
done

# Einfacher Schutz vor Spoofing
$IPT -I INPUT -m conntrack –ctstate NEW,INVALID -p tcp –tcp-flags SYN,ACK SYN,ACK -j REJECT –reject-with tcp-reset

# Einfacher DDoS-Schutz
$IPT -A INPUT -p tcp -m tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -j ACCEPT

# Verwerfe alle ungültigen Pakete
$IPT -A INPUT -m state –state INVALID -j DROP
$IPT -A FORWARD -m state –state INVALID -j DROP
$IPT -A OUTPUT -m state –state INVALID -j DROP

# Einfacher Schutz vor Port-Scannern
# Angreifende IP wird für 24 Stunden gesperrt
# (3600 x 24 = 86400 Sekunden)
$IPT -A INPUT -m recent –name portscan –rcheck –seconds 86400 -j DROP
$IPT -A FORWARD -m recent –name portscan –rcheck –seconds 86400 -j DROP

# Freigeben der IP nach 24 Stunden
$IPT -A INPUT -m recent –name portscan –remove
$IPT -A FORWARD -m recent –name portscan –remove

# Erlaube ICMP
$IPT -A INPUT -p icmp –icmp-type 3 -j ACCEPT
$IPT -A INPUT -p icmp –icmp-type 8 -j ACCEPT
$IPT -A INPUT -p icmp –icmp-type 8 -j LOG –log-level debug –log-prefix „PING IP_TABLES:“
$IPT -A INPUT -p icmp –icmp-type 11 -j ACCEPT
$IPT -A INPUT -p icmp –icmp-type 12 -j ACCEPT

# Schutz vor Brute-Force-SSH-Angriffen
$IPT -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –set –name SSH –rsource
$IPT -A INPUT -p tcp -m tcp –dport 22 -m recent –rcheck –seconds 30 –hitcount 4 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 22 -m recent –rcheck –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j LOG –log-prefix „SSH brute force “
$IPT -A INPUT -p tcp -m tcp –dport 22 -m recent –update –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 600 –hitcount 3 –rttl –name SSH -j DROP

# Schutz vor Brute-Force-SSH-Angriffen auf port 2222
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m state –state NEW -m recent –set –name SSH –rsource
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m recent –rcheck –seconds 30 –hitcount 4 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m recent –rcheck –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j LOG –log-prefix „SSH brute force “
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m recent –update –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m state –state NEW -m recent –update –seconds 600 –hitcount 3 –rttl –name SSH -j DROP

# Erlaube SSH
$IPT -A INPUT -p tcp -m tcp –dport 2222 -j ACCEPT

# Erlaube Ping
$IPT -A OUTPUT -p icmp -m icmp –icmp-type 8 -j ACCEPT

# Erlaube https
$IPT -A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

Auch für die Erweiterung der Firewall habe ich ein passendes Systemd-Skript geschrieben:

[Unit]
Description=Firewall
After=network.target
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/home/stka/firewall-start.bash
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Ein Brut-Force Angriff erscheint jetzt mit der folgenden Meldung im Log:

SSH brute force IN=wlan0 OUT= MAC=d8:3a:dd:24:da:8d:d0:6e:de:c3:ec:30:08:00 SRC=45.135.232.177 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=37812 DF PROTO=TCP SPT=53954 DPT=2222 WINDOW=42340 RES=0x00 SYN URGP=0

Die IP-Adresse wird dann gesperrt. Aber keine Angst, da kommen gleich die nächsten.
Gerne hätte ich noch mit xtables-addons-common eine Erweiterung für iptables geladen, die auf Grund von Listen ganze Länder blockiert, aber leider bekomme ich das benötigte Kernelmodul auf meinem Raspberry nicht zum Laufen. Aber der Anfang ist gemacht.

Alle Skripte können hier runtergeladen werden.

Im zweiten Teil will ich jetzt meine Installation der Opencloud Anwendung beschreiben. Auf der Webseite zu opencloud www.opencloud.eu werden verschiedene Möglichkeiten zur Installation beschrieben. Siehe da! Es gibt auch eine Anleitung für die Installation auf dem Raspberry.  Also alles mit docker compose installieren. Ich habe schon ein paar mal einen Docker Container installiert, aber in so einem Umfang? Nö! Aber den Mutigen gehört die Welt, also frisch ans Werk.

Das Einrichten des Routers habe ich ja schon im ersten Teil beschrieben. Alle Kommandos von Abschnitt 1.4 bis 1.8 habe ich, mit kleinen Änderungen bei der Einrichtung des Datenträgers, einfach aus der Anleitung kopiert. Hat alles geklappt. Ach so, den Installationspfad habe ich angepasst. Die Installation von Software im $HOME eines Benutzers? Och nöööö muss nicht. Meine Installation liegt jetzt in /opt/opencloud, auch meine ssd für die Daten habe ich dort gemountet.

Der Zugriff von Außen ist in der Anleitung ganz gut beschrieben, nur fehlt dort ein wichtiger Teil, die Einrichtung der Netzwerkzugriffe für:

1. COLLABORA_DOMAIN=
2. WOPISERVER_DOMAIN=
3. TRAEFIK_DOMAIN=
4. OC_DOMAIN=

Es gibt auf der Webseite noch zwei weiter Anleitungen, einmal eine für die Installation direkt auf dem Blech und dann noch drei verschiedene Docker Varianten. Leider konnte ich in keiner eine genaue Beschreibung zur Einrichtung von DNS finden. An vielen Stellen, auch an bei anderen Quellen im Internet, steht immer das die Domänen auf 127.0.0.1 in der /etc/hosts eingetragen werden können. Das hat bei mir nicht geklappt. Also schnell in mein Konto bei no-ip.com angemeldet und die entsprechende cname-records erstellt. Meine Records bei no-ip, in die Konfigurationsdatei .env eingetragen, sehen jetzt wie folgt aus:

TRAEFIK_DOMAIN=traefikstka.example.net
OC_DOMAIN=stka.example.net
COLLABORA_DOMAIN=collaborastka.example.net
WOPISERVER_DOMAIN=wopiserverstka.example.net

Wobei der Eintrag für OC_DOMAIN mein A-record ist und alle anderen eine cname auf stka.example.net. So eingetragen, werden auch keine weiteren Einträge in der /etc/hosts benötigt.

Dann endlich war es soweit, die Anmeldung funktionierte und auch der Aufruf der Anwendungen aus Collabora funktioniert, aber der Browser hat immer noch über das Zertifikate gemeckert, denn noch ist das selbst signiert. Fehlte also noch Let’s encrypt für das Zertifikat. Jetzt hatte ich schon auf der Webseite von Let’s encrypt geschaut, wie man dort Zertifikate erstellt und einträgt, aber schau mal einer an, das macht Opencloud alles für mich. Erst ein Test ob alles klappt, dafür wird in der Datei .env die folgenden Zeile angepasst:

TRAEFIK_ACME_CASERVER=https://acme-staging-v02.api.letsencrypt.org/directory

So wird ein Testzertifikat erstellt. Was dort passiert wird im Kommentar zum Parameter genau beschrieben. Docker compose neu gestartet, mit dem Browser zugegriffen und sieh da, das Testzertifikat wurde genau so angezeigt wie im Kommentar beschrieben.

Dann docker compose wieder stoppen und die nicht mehr benötigten Zertifikate mit dem Kommando

docker volume rm opencloud_full_certs

löschen. Die vorher eingetragene Zeile in der Datei .env auskommentieren und docker compose wieder starten. Trommelwirbel, Zugriff mit dem Browser und super jetzt wird die Domäne mit einem gültigen Zertifikat im Browser angezeigt.

Zum Abschluss hier mal alle aktiven Zeilen meiner Konfiguration aus der Datei .env:

LOG_DRIVER=
TRAEFIK_DASHBOARD=
TRAEFIK_DOMAIN=traefikstka.example.net
TRAEFIK_BASIC_AUTH_USERS=sperduper:$$2y$$05$$u3X…
TRAEFIK_ACME_MAIL=stefan@dummy.de
OPENCLOUD=:opencloud.yml
OC_DOCKER_IMAGE=opencloudeu/opencloud-rolling
OC_DOCKER_TAG=
OC_DOMAIN=stka.example.net
ADMIN_PASSWORD=Uecs…
DEMO_USERS=
LOG_LEVEL=
OC_CONFIG_DIR=/opt/opencloud/config
OC_DATA_DIR=/opt/datadisk
DECOMPOSEDS3_ENDPOINT=
DECOMPOSEDS3_REGION=
DECOMPOSEDS3_ACCESS_KEY=
DECOMPOSEDS3_SECRET_KEY=
DECOMPOSEDS3_BUCKET=
MINIO_DOMAIN=
START_ADDITIONAL_SERVICES=“notifications“
EXTENSIONS=:web_extensions/extensions.yml
UNZIP=:web_extensions/unzip.yml
DRAWIO=:web_extensions/drawio.yml
JSONVIEWER=:web_extensions/jsonviewer.yml
PROGRESSBARS=:web_extensions/progressbars.yml
EXTERNALSITES=:web_extensions/externalsites.yml
COMPANION_IMAGE=
COMPANION_DOMAIN=
COMPANION_ONEDRIVE_KEY=
COMPANION_ONEDRIVE_SECRET=
TIKA=:tika.yml
TIKA_IMAGE=
COLLABORA=:collabora.yml
COLLABORA_DOMAIN=collaborastka.example.net
WOPISERVER_DOMAIN=wopiserverstka.example.net
COLLABORA_ADMIN_USER=superduper
COLLABORA_ADMIN_PASSWORD=NnJ…
COLLABORA_SSL_ENABLE=false
COLLABORA_SSL_VERIFICATION=false
CLAMAV_DOCKER_TAG=
INBUCKET_DOMAIN=
COMPOSE_PATH_SEPARATOR=:
LDAP_ADMIN_PASSWORD=
LDAP_MANAGER_DOMAIN=
IDP_DEFAULT_SIGNIN_PAGE_TEXT=
KEYCLOAK_DOMAIN=
KEYCLOAK_REALM=
KEYCLOAK_ADMIN_USER=
KEYCLOAK_ADMIN_PASSWORD=
COMPOSE_FILE=docker-compose.yml${OPENCLOUD:-}${TIKA:-….

Ein kleiner Wermutstropfen auch hier: Nachdem alle soweit läuft, wollte ich gerne den amavis Virenscanner noch einbinden, aber leider gibt es dafür keinen Docker container.

Im nächsten Teil werde ich dann noch zeigen, wie ich die iptables Firewall erweitert habe und wie ich dafür sorge, dass sowohl Opencloud als auch die Firewall automatisch beim Systemstart gestartet werden.

Dieses ist der erste Artikel einer Reihe in der ich über die Erfahrungen und die Installation einer Opencloud-Instanz auf einem Raspberry berichten werde. Angefangen von der Installation des Pi bis zur Konfiguration der Opencloud-Instanz.

Warum Opencloud, es gibt doch schon so viele andere Cloud-Lösungen? Ich habe mich für Opencloud entschieden, weil die gesamte Entwicklung in Deutschland stattfindet und die Software auf dem aktuellen Stand ist. Auch ist die Installation recht einfach, alle Funktionen werden über Docker compose bereitgestellt. Außerdem wird mit Opencloud gleich collaborate als browserbasierte Officelösung eingerichtet. Mehr zu Opencloud unter www.opencloud.eu.

Warum überhaupt eine eigene Lösung hier zu Hause? Alles was es sonst so gibt, wird entweder irgendwo in den USA gespeichert (wer will das noch) oder kostet mehr als das was ich für den Raspberry, die ssd und alles was drumherum benötigt wird, bezahlt habe. Klar, um die Backups muss ich mich selber kümmern, aber das geht dann auch später automatisch.

Im ersten Artikel geht es erst einmal um die Grundeinrichtung des Raspberry.

Als Grundlage dient ein Raspberry 4 mit 8 Gb RAM und einer 32GB SD-Karte für das Betriebssystem. Für die Daten habe ich eine 4TB ssd gekauft und über den USB-3 Port mit dem Raspberry verbunden. Da sollte für eine Heimanwendung ausreichen.

Nach der Installation von Raspbian (Debian 12) geht es erst einmal um die Absicherung der Zugriffe. Dazu wird der sshd angepasst und der Google-Authenticator installiert um später eine zwei Faktor Authentifizierung durchführen zu können. Eine Anmeldung per einfachem Passwort soll später nicht mehr möglich sein.

Installation des Google-Authenticators

sudo apt install libpam-google-authenticator

Anschließend muss die Datei /etc/pam.d/ssh wie folgt anpassen:

port 2222
# @include common-auth
auth required pam_google_authenticator.so
AuthenticationMethods publickey,keyAuthenticationboard-interactive
KbdInteractiveAuthentication yes

Die include-Zeile muss auskommentiert werden, da sonst der Inhalt der Datei common-auth alles übersteuert auch die gerade gesetzt Verwendung des Google-Authenticators.

Anschließend wird der sssd neu gestartet, um die Änderungen wirksam werden zu lassen. Rufen Sie jetzt auf dem Raspberry als Benutzer das Programm google-authenticator auf, das Programm leitet Sie durch die Einrichtung. Scannen Sie den QR-Code mit einer entsprechenden App auf Ihrem Smartphone um den zweiten Faktor generieren zu können.

Damit der Raspberry auch von Außen erreichbar ist, benötigen Sie einen DNS A-Record der dynamisch aktualisiert wird. Ich habe dafür ein Konto bei no-ip.com eingerichtet. Hier können Sie dann später auch die cname-Records für Opencloud einrichten.

Zusätzlich müssen Sie auf Ihrem Internet-Router eine Portweiterleitung auf den Port 2222 (dem geänderten ssh-Port) und schon mal auf Port 443 einrichten, sodass später die Zugriffe aus dem Internet auf Ihren Raspberry weitergeleitet werden.

Wenn Sie alle diese Einrichtungen vorgenommen haben, sollte ein Zugriff über den dynamischen A-Record möglich sein. Wenn die Installation und Konfiguration von Opencloud abgeschlossen ist, wird später noch ein iptables-Skript hinzukommen, das dann noch ssh-Angriffe und Portscanns blocken soll. Da aber bei der Installation von Opencloud bereits ein Firewallskript, basierend auf iptables, eingerichtet wird, hänge ich mein Skript später nur an die bestehende Konfiguration an.
Damit wäre dann der erste Teil, die Vorbereitung des Raspberry, abgeschlossen.

Im zweiten Teil geht es dann um die Installation und Konfiguration von Opencloud inklusive der Einrichtung der DNS-Records bei no-ip.

Heute habe ich den ersten Teil der neuen Ansible-Rollen für die Erstellung einer multi Providerumgebung in mein git-Repository hochgeladen. Die Rollen stehen nicht nur für die Besitzer des Ansible-Buchs zur Verfügung, sonder können auch so genutzt werden. Die Rollen sind Bestandteil der Downloads zum Buch und können komplett mit dem Kommando „git clone https://github.com/stkania/openldap-in-der-praxis“ heruntergeladen werden.

Im zweiten Teil wird es dann Rollen für die Einrichtung von Kerberos und der Einbindung in OpenLDAP geben.

Bei OpenLDAP werden sich zum Anfang des Jahres 2025 die Versionen wie folgt ändern:

• Die Version 2.5 wird auslaufen, bekommt aber noch bis 15.01.2027 Sicherheitsupdates. Nach diesem Datum bekommt die Version den Status „historical“ und erhält dann keine Updates oder Sicherheitspatches mehr.
• Die Version 2.6 wird zur neuen LTS-Version werden.
• Im Herbst 2024 wird die Version 2.7 erscheinen, bei dieser Version handelt es sich um die neue „feature Release“ Version. Also mit allen Neuerungen.

Die Umstellung vom 2.5 auf 2.6 kann mit der laufenden Konfiguration stattfinden. Nur beim Einsatz des Loadbalancers muss die Konfiguration angepasst werden.

Die Replikation zwischen Version 2.5 und 2.6 läuft ohne Probleme, so kann ein Server nach dem anderen Umgestellt werden.

Für die Verwaltung von Postfix-Abfragen werden die beiden Attribute mailacceptinggeneralid und maildrop benötigt. Leider gibt es kein Standardschema in dem diese beiden Attribute vorhanden sind. Eine Lösung dafür wird hier angeboten. Aber dort gibt es nur das Schema für die Einbindung über die slapd.conf, die LDIF-Datei für die dynamische Konfiguration fehlt hier leider. Ich habe die Datei umgewandelt und stelle sie hier zum Download bereit. Die LDIF-Datei für das Schema können Sie einfach mit dem Kommando ldapadd -Y external -H ldapi:/// -f postfix.ldif in die Konfiguration eingefügt. Anschließend können Sie die Objektklasse allen Benutzer zuweisen. Da beide Attribute nur MAY-Attribute sind, kann die Objektklasse auch ohne Werte den Benutzern zugewiesen werden.

Was ist aber mit dem LAM? Kann der LAM erweitert werden, sodass beim Anlegen eines Benutzer die Objektklasse und die Attribute gleich vergeben werden können? Ja, das geht, aber nur in der LAM-Pro Version. Dazu wird das Profil des LDAP-Servers im LAM angepasst. Die folgenden Schritte sind dafür notwendig:

Nach dem Öffnen des Profiles wird im Karteireiter Module, das Modul customFields zum Benutzer hinzugefügt.

Dann auf den Karteireiter Moduleinstellung wechseln, das neue Modul suchen, einen Alias-Name eintragen:

und anschließen auf Neue Gruppe anlegen klicken. Daraufhin wird das Fenster um die Möglichkeit der Eingabe einer Objektklasse erweitert. Hier tragen Sie die Objektklasse PostfixUser ein. Jetzt fehlen dann nur noch die beiden Felder für die beiden Attribute der Objektklasse. Um die Felder zur Gruppe hinzuzufügen klicken Sie auf „Feld hinzufügen“.

Im nächsten Bild sehen Sie, am Beispiel des Attributs maildrop, wie Sie die Felder hinzufügen. Bei beiden Feldern handelt es sich um Textfelder.

Wenn Sie beide Felder hinzugefügt haben, können Sie bei der Beschriftung der Gruppe noch einen Namen vergeben. Dieser Name wird dann als zusätzliches Feld beim Anlegen eines Benutzer angezeigt.
Speichern Sie die Änderungen und melden Sie sich anschließend am LDAP-Server an. Wenn Sie jetzt einen neuen Benutzer anlegen, sehen Sie die neue Gruppe und können dann dort die Werte ergänzen.

Mal was einfaches zum Thema Sicherheit in Linux-Systemen. Es müssen nicht immer die großen Klatschen sein, kleine Dinge helfen da auch.

Immer wieder (oder sagen wir leider immer noch) sehe ich, dass beim Wechsel zum root-Konto auf einem System nur „su“ und nicht „su -„ eingegeben wird. Auch in Bereichen an denen sonst alles soooooo super abgesichert ist. Aber was ist das Problem dabei?

Bei einem einfachen „su“ behält der Benutzer „root“ die Umgebung, mit allen gesetzten Variablen, auch „$PATH“. Wenn jetzt der Benutzer das aktuelle Verzeichnis, also „.“ an den Anfang von „$PATH“ setzt, werden alle eingegebenen Kommandos immer erst im aktuellen Verzeichnis gesucht. Ganz schön dumm. Denn so kann ein Benutzer dem Admin mal schnell ein kleines Skript unterjubeln und damit das Passwort abfangen. Schön ist da sowas:

#!/bin/bash
PWALT=““
PWNEU1=““
PWNEU2=““
echo „Passworts für $USER wird geändert.“
echo -n „Geben Sie das aktuelle Passwort ein: “
stty -echo
read PWALT
echo „“
stty echo
echo -n „Geben Sie ein neues Passwort ein: “
stty -echo
read PWNEU1
echo „“
stty echo
echo -n  „Geben Sie das neue Passwort erneut ein: “
stty -echo
read PWNEU2
echo „“
stty echo
sleep 2
echo „Die Passwörter stimmen nicht überein.“
echo „passwd: Bearbeitungssfehler des Legitimierungszeichens“
echo „passwd: Passwort nicht geändert“
echo $PWALT > ${HOME}/passklau
echo $PWNEU1 >> ${HOME}/passklau  
echo $PWNEU2 >> ${HOME}/passklau  
mv passwd.bash passwd1.bash

Das Skript wird mit dem name passwd abgespeichert. Wenn jetzt der Admin, nach der Eingabe von „su“ sein Passwort ändern will, ruft er das Skript auf. Na vertippen kann sich jeder mal. Beim zweiten Aufruf klappt es dann ja, also alles Ok.

Wird stattdessen „su -“ genutzt, ist das identisch mit einem Login, der „root“ erhält seine eigene Umgebung und würde nicht in Falle laufen.

Sie sehen, es macht Sinn „su -“ zu nutzen und es ist absolut Sinnvoll, dass das aktuelle Verzeichnis NICHT in $PATH eingetragen ist.