Henrikx schriebTomb verlangt explizit root laut den Howtos. Auf einem Einzelplatzrechner kann das als Sicherheitsfunktion gewertet werden.
Das Script selbst ruft an mehreren Stellen
sudo auf.
$ grep sudo tomb | sed s/".*\(sudo [0-9a-z\.]*\).*"/"\1"/g | uniq
sudo mkfs.ext3
sudo losetup
sudo mkdir
sudo file
sudo dmsetup
sudo losetup
sudo gpg
sudo cryptsetup
sudo umount
sudo cryptsetup
sudo fsck
sudo tune2fs
sudo mkdir
sudo mount
sudo chown
sudo chmod
sudo umount
sudo mount
sudo cryptsetup
sudo e2fsck
sudo resize2fs
sudo cryptsetup
sudo umount
sudo cryptsetup
sudo losetup
sudo
So ein Script (bzw. so viele
sudo-Berechtigungen für so viele Systemkritische Programme), sollte man nicht vergeben. Schon gar nicht für ein Script, das „aus Sicherheitsgründen“ geschaffen wurde.
Henrikx schriebDie von dir aufgeführten Befehle werden ja per Script aufgerufen. Mount geht ja automatisch auf /media/secret.tomb/. In wie weit das zu ändern ist, weiß ich z.Z. noch nicht.
Nun, gemäß Script muss für die genannten Befehle die Möglichkeit bestehen, dass der User sie per
sudo aufrufen kann. Aus Bequemlichkeitsgründen wohl ohne Passwort (sonst artet das in eine Passwort-Eingebe-Orgie aus *g*) – aber das ist hier zweitrangig, Tatsache ist, dass der User die Befehle per
sudo ausführen müssen kann.
Was hindert den User daran,
sudo umount / einzugeben? Oder
chown mallory:user /root? Oder
sudo mount -oloop /home/mallory/hacking.iso /usr/bin? Oder einfach nur
mkfs.ext3 /dev/sda1, um zu testen, ob der Administrator für
/dev/sda1 wirklich ein Backup hat? *g* … Oder die ganzen Befehle in eigenen Scripts anderweitig zu verwenden?