Moment, ich habe es Interesse halber gerade ausprobiert, ein
Ja, aber mit den Rechten des Users, der das
sudo aufgerufen hat.
Rich (BBCode):
pi@pi4:~ $ touch /home/pi/test; chmod 600 /home/pi/test; sudo chown strongswan:nogroup /home/pi/test; ls -l /home/pi/test
-rw------- 1 strongswan nogroup 0 Dec 21 18:54 /home/pi/test
pi@pi4:~ $ sudo -u strongswan echo new_line >> /home/pi/test
-bash: /home/pi/test: Permission denied
pi@pi4:~ $ sudo -u strongswan bash -c "echo new_line >> /home/pi/test"
pi@pi4:~ $ cat /home/pi/test
cat: /home/pi/test: Permission denied
pi@pi4:~ $ sudo -u strongswan cat /home/pi/test
new_line
pi@pi4:~ $
Ich habe zwar keinen Benutzer
asterisk auf dem betreffenden Pi, aber der Benutzername spielt ja nicht wirklich die entscheidende Rolle.
Außerdem sollte die Mitgliedschaft in der GPIO Gruppe zu nicht viel mehr berechtigen als die GPIO Pins zu bedienen.
Schon das ist zuviel. In einem Dialplan kann man auch leicht Fehler machen (z.B. die Übernahme von ungeprüften Eingaben bei der Ausführung von Shell-Funktionen - und viele der Channel-Variablen sind durch einen Anrufer zu beeinflussen, u.a. die Caller-ID) und nach dem Prinzip, daß "elevated privileges" so spät wie möglich erlangt und so früh wie möglich wieder entzogen werden sollten, ist es falsch, das gesamte Skript in einem
sudo-Kontext aufzurufen, wenn es auch ausreichen würde, die Ausführung EINZELNER Kommandos in einem "elevated state" zu veranlassen.
Nimmt man den Benutzer
asterisk in die Gruppe
gpio auf, hat er VOLLEN Zugriff auf ALLE GPIO-Pins und kann deren Mappings ins Userland verändern (neue hinzufügen oder bestehende entfernen) - angesichts denkbarer(!) Schwächen in der Implementierung eines Dialplans irgendwie nichts, was ICH (andere mögen da anderer Ansicht sein) so gerne hätte.
System(sudo /abs/pfad/18high.sh &)
Was die parallele Ausführung des Shell-Skripts
18high.sh (das ist ja der Name, den der TO irgendwo vorher mal "vergeben" hat) jetzt besser machen sollte (das wäre ja das abschließende
& in dem Aufruf), verstehe ich nicht und wenn in
18high.sh die einzelnen Kommandos (je nachdem, wie kompliziert man das macht, ist es ja nur ein einziges
echo-Kommando - wenn das Gegenstück
18low.sh heißen sollte) mittels
sudo aufgerufen werden, braucht man nicht für das gesamte Skript die erhöhten Rechte (es KÖNNTE ja auch mehr als eine Zeile in diesem Skript stehen).
Daß die Skript-Datei irgendwo "sicher" zu speichern ist (z.B. in
/usr/local/bin, was hoffentlich auch in einer Zeile
Defaults secure_path= in der
/etc/sudoers eingeschlossen wird in den Suchpfad) und niemand außer dem Superuser dort Schreibrechte haben sollte und die Gruppe bzw. ggf. noch "others" nur Lese- und Ausführrechte erhält, versteht sich sicherlich von selbst.
Oder, ich weiß nicht ob ich's schon gesagt habe, auf sysfs verzichten und den GPIO Pin mit Python steuern
Inwiefern macht das dann das gesamte Konstrukt irgendwie sicherer? Soweit ich weiß, arbeiten diese Python-Klassen mit Memory-Mapped-I/O für die GPIO-Pins und da auch dieses Mapping erst einmal über
/dev/mem einzurichten wäre, sind dann für den Python-Aufruf ebenso wieder Superuser-Rechte erforderlich.
Angesichts der Tatsache, daß hier weder die Abfrage von Pins noch irgendein Trigger beim Ändern eines Signals verwendet werden, wäre Python (m.E.) totaler Overkill, zumal ich mich frage, woher die Aussage:
Das Pseudo Filesystem ist übrigens als veraltet zu betrachten
wohl kommen mag - zumal das ohne den Zusatz "für den GPIO-Zugriff" viel zu pauschal ist und an der Realität vorbei geht. Es werden - ganz im Gegenteil - sogar immer mehr Einstellungen über Pseudo-Dateisysteme zugänglich gemacht ... man braucht ja nur mal ein
mount einzugeben (meinetwegen im Raspbian) und zu zählen, wieviele Mountpoints mit derartigen Pseudo-Dateisystemen belegt sind.
Ich bin sogar der Ansicht, daß man in der
/etc/sudoers das Ausführen einer
bash-Shell (ohne Kennworteingabe) und darin eines
echo-Kommandos auf exakt den Pfad
/sys/class/gpio/gpio18/value festlegen kann (probiere ich aber erst später selbst aus), denn da steht im
man-File das Folgende:
sudo allows shell-style wildcards (aka meta or glob characters) to be used in host names, path names and command line arguments in the sudoers file.
und das sollte sich - mit passender "Formulierung" - dann auf das Schreiben der Werte
0 bzw.
1 in die Datei
/sys/class/gpio/gpio18/value beschränken lassen. Das Mapping des GPIO-Pins 18 ins Userland ist ohnehin Aufgabe der System- oder Asterisk-Initialisierung - das wird man ja eher nicht bei JEDEM Aufruf des "Klingel-Skripts" machen wollen.
Und by the way ... daß der Aufruf des Skripts am besten mittels
NOPASSWD in der
/etc/sudoers erlaubt werden sollte:
Weil dann könnte man den Asterisk User per sudoers zum Aufruf dieses einen Skripts berechtigen, ohne ihm anderweitig sudo Rechte geben zu müssen. Läuft das Skript als su, wird auch alles darin mit su Rechten ausgeführt.
, stand (meinerseits) schon in
#9.
