Stand heute: Version 944:

login erforderlich.
Setzt username + passwort in Environment und startet neue bash

Nachteile:
Environment lässt sich von anderen Benutzern auslesen
neue Shell macht Schwierigkeiten, je nach Distribution, History geht verloren
schwierig, nach Passwort zu fragen, wenn es für eine Aktion erforderlich ist, aber noch nicht eingegeben

Umstellung
Ziele:
höhere Sicherheit
keine neue Shell
login daten werden nachgefragt und werden gespeichert, wenn es erforderlich ist.

Vorgehen:
ein eindeutiger Indikation für eine Anmeldung wird benötigt, z.B. die Zeit des Logins.
Daraus wird der Name für eine Session-Datei gebildet,
z.B. ~/.dasscm/session/`date +"%Y%m%d%H%M%S"`
Diese Name wird in der Umgebungsvariable DASSCM_SESSION hinterlegt,
die in /etc/profile.d/dasscm.sh gesetzt wird.
/etc/profile.d/dasscm.sh:

DATE=`date +'%Y%m%d%H%M%S'`
SESSION_DIR=~/.dasscm/session/
if test -w $SESSION_DIR && DASSCM_SESSION_FILE=`mktemp --dry-run --tmpdir $SESSION_DIR $DATE-XXXX`; then
    export DASSCM_SESSION_FILE
    export DASSCM_SESSION_TIME="`printf "%i.%05i\n" $DATE $RANDOM`
fi

Bei einem "dasscm login" werden Benutzername und Passwort mit symmetisch $DASSCM_SESSION_TIME verschlüsselt.
Da ansonsten Perl Module benötigt werden,
kann stattdessen mittels openssl ver- und entschlüsselt werden:
{{{
joergs@ting:/tmp/test> printf "1234\nDASSCM_USERNAME=halloX3\nDASSCM_PASSWORD=XXX\n" | openssl des3 -e -base64 -pass stdin -salt  -out t64.des
joergs@ting:/tmp/test> echo "1234" | openssl des3 -d -base64 -pass stdin -salt -in t64.des
halloX3
}}}


Potentielle Problemfälle:
- wenn /etc/profile.d/dasscm nochmals aufgerufen wird, werden die Variablen überschrieben. Dies sollte aber nur bei einer neuen Shell passieren und die hätten die Variablen heute auch schon überschrieben.
  TODO: prüfen, ob Variablen schon gesetzt sind
- --dry-run macht mktemp potentiell unsicher. Da wir als erste Komponente aber das sekundengenaue Datum verwenden, sollten ohnehin keine Probleme auftauchen
- mktemp nicht installiert, openssl nicht installiert
- session Dateien werden nicht automatisch wieder gelöscht
- DASSCM_SESSION_FILE ist nicht anlegbar/schreibbar
- was tun, wenn SESSION_DIR nicht schreibbar ist?
