user www-data en toegang tot seriele poort

[Promy]

Ik wil via een webpagina (php) een python script uitvoeren dat gebruik maakt van de seriele poort via pyserial (import serial).
Als ik het script uitvoer als root via de commandline, dan werkt het perfect.
Als ik het echter aanroep via het php script, dan werkt het script tot voor de lijn die de seriele poort opent.
Ik vermoed dat er dus een probleem is met de rechten.

Ik heb al geprobeerd om de gebruiker www-data (want deze voert het script uit) sudo rechten te geven door via visudo de regel www-data ALL=(ALL) ALL toe te voegen,en het sudo bij het commando te zetten in php, maar het lijkt niet te werken (script wordt dan zelfs niet uitgevoerd.)

Heeft er iemand een idee hoe ik dit kan oplossen?

[Hero of Time]

Heb je al gekeken naar de rechten op de /dev/ node? Andere dingen die je via Google mogelijk kon vinden? Misschien is het zo eenvoudig als www-data in de dialout groep zetten.

Ik heb al geprobeerd om de gebruiker www-data (want deze voert het script uit) sudo rechten te geven door via visudo de regel www-data ALL=(ALL) ALL toe te voegen,en het sudo bij het commando te zetten in php, maar het lijkt niet te werken (script wordt dan zelfs niet uitgevoerd.)

Logisch, het staat te wachten op een wachtwoord. Heb je al eens 'man sudoers' gedaan om de syntax te snappen?

[DeBolle]

Welke Linux je hebt zou handig zijn om te weten, maar in het algemeen zijn alle devices owned door root. Applicaties kunnen er dan niet bij en het is meestal geen goed idee een applicatie als root te draaien.
Het gemakkelijkst is dan de nodige devices www-data als owner te geven en dat gaat alleen goed als je gebruik maakt van /etc/udev/rules.d scripts.
Normaliter worden devices namelijk voortdurend gereset naar de oorspronkelijke owner, dus simpelweg een chown gaat niet werken.

Stel dan eerst vast welke seriele poort je gaat gebruiken en maak een bestand aan in /etc/udev/rules.d. Hier doe ik het voor ttyS2 en 3:

code:

$ ls -la /dev/ttyS*
crw-rw----. 1 root dialout 4, 64 Jan  3  2014 /dev/ttyS0
crw-rw----. 1 root dialout 4, 65 Jan  3  2014 /dev/ttyS1
crw-rw----. 1 root dialout 4, 66 Jan  3  2014 /dev/ttyS2
crw-rw----. 1 root dialout 4, 67 Jan  3  2014 /dev/ttyS3

$ sudo vi /etc/udev/rules.d/49-ttyS.rules
KERNEL=="ttyS2", NAME="%k", OWNER="www-data"  MODE=0660
KERNEL=="ttyS3", NAME="%k", OWNER="www-data"  MODE=0660

Reboot en klaar:

code:

$ ls -la /dev/ttyS*
crw-rw----. 1 root     dialout 4, 64 Jan  3  2014 /dev/ttyS0
crw-rw----. 1 root     dialout 4, 65 Jan  3  2014 /dev/ttyS1
crw-rw----. 1 www-data dialout 4, 66 Jan  3  2014 /dev/ttyS2
crw-rw----. 1 www-data dialout 4, 67 Jan  3  2014 /dev/ttyS3

Dit is op een RHEL6.4 overigens. Ook letten op de volgorde (nummering) van de rule, je wilt niet dat een later script de boel weer reset.
Oh, zet de sudoers even weer terug naar default als je verder die entry niet gebruikt, het is niet echt handig om www-data alle permissies te geven naar mijn mening.

[Promy]

Voor zover ik begrepen had uit de man van sudo was dat door het toevoegen van de user via visudo er geen wachtwoord gevraagd werd voor de sudo op die manier...
De linux in kwestie is een raspberry pi met raspbian erop.

het gewoon toevoegen van de user www-data aan de groep dialout (zonder reboot weliswaar), lost het probleem niet op...

[ Voor 19% gewijzigd door Promy op 03-01-2014 23:34 ]

[johnkeates]

Soms ben je beter af door de groepen te gebruiken, zoals dialout in dit geval, of serial. Dan kan je je devices voor normaal gebruik beschikbaar houden, maar door je scripts als www-data:serial te draaien kan je ze beperkt extra rechten geven zonder dat ze opeen system-wide nare dingen kunnen doen.

[Hero of Time]

Promy schreef op vrijdag 03 januari 2014 @ 23:28:
Voor zover ik begrepen had uit de man van sudo was dat door het toevoegen van de user via visudo er geen wachtwoord gevraagd werd voor de sudo op die manier...

Lees 'm dan nog maar een keer, want je hebt 'm niet goed begrepen.

@anderen: laat hem zelf uitzoeken, leert-ie veel meer van

het gewoon toevoegen van de user www-data aan de groep dialout (zonder reboot weliswaar), lost het probleem niet op...

Logisch, als jij jezelf aan een groep toevoegt, heb je ook die rechten nog niet totdat je opnieuw aanmeld. Bij www-data is het wat lastiger, een restart van apache zou kunnen werken, maar een reboot is net zo effectief en weet je 't tenminste zeker.

[Verwijderd]

DeBolle schreef op vrijdag 03 januari 2014 @ 19:10:

Het gemakkelijkst is dan de nodige devices www-data als owner te geven en dat gaat alleen goed als je gebruik maakt van /etc/udev/rules.d scripts.

Nee. We gaan toch geen rechten op devices aanpassen als er iemand gebruik moet kunnen maken van een decive? De standaard manier is om gewoon de user lid te maken van de groep. Dat is de reden dat die groep bestaat, dat is de reden dat de groep read/write permissions heeft op de device. De enige reden.

Een user toevoegen aan een groep maakt niks kapot. Een device owner wijzigen maakt potentieel van alles kapot. Iemand die geen expert is moet nooit aan dit soort dingen komen. Iemand die wel expert is alleen als er een verdomd goede reden voor is. En voor iets triviaals als dit is het niet goed te praten om aan udev rules te komen.

$ sudo vi /etc/udev/rules.d/49-ttyS.rules
KERNEL=="ttyS2", NAME="%k", OWNER="www-data" MODE=0660
KERNEL=="ttyS3", NAME="%k", OWNER="www-data" MODE=0660
[/code]

Reboot en klaar:

Voor de duidelijkheid en voor de archieven: Nee

Als je geen belangrijke devices aan je seriële poorten gaat hangen, dan kun je kiezen voor:

usermod -aG dialout www-data

De mooiste manier om dit probleem op te lossen, is echter als volgt:
Je maakt een user aan die alleen wordt gebruikt voor communicatie van jouw script met de device aan die ene seriële poort. Zorg met een sudo regel dat de gebruiker www-data zonder wachtwoord alleen dat ene script mag aanroepen.

Zo heb je gezorgd dat www-data niet zomaar onbeperkte toegang heeft, en is de verdere beveiliging afhankelijk van de kwaliteit van je script.

[Hero of Time]

Cheatah, kan je uitleggen waarom sudo beter is dan groepslidmaatschap? Sudo is bovendien niet altijd aanwezig (als je Debian installeert en je geeft een root wachtwoord op, krijg je geen sudo en moet je 'm later handmatig installeren). Daarnaast zijn er ook bepaalde beveiligingsrisico's met sudo. Bijvoorbeeld, het script wordt aangepast. Dan kan je alles als root doen, want dat ene script mag je als root uitvoeren, met alles wat erin staat.

[CyBeR]

Inderdaad, sudo preventeert je dan wel een ander script uit te voeren maar dat script draait nog altijd als root en kan dus alles doen.

www-data in de dialout groep zetten is een veel beter idee.

[DeBolle]

Het probleem wat ik heb met willekeurige users toevoegen aan group dialout is dat ik de desbetreffende user meteen rw access geef tot alle devices in die group. Dat maakt de oplossing veel breder van scope dan het probleem.
Ik blijf daarom bij mijn oplossing om alleen het betreffende device dat account als owner te geven. Gaat er iets kapot dan gaat het alleen om het betreffende device en niet om alles in de group.

[CyBeR]

De dialout groep heeft alleen toegang tot seriele poorten.

[CAPSLOCK2000]

Als je nog meer controle wil dan kun je ACLs gebruiken (zie setfacl).

[Verwijderd]

Hero of Time schreef op zaterdag 04 januari 2014 @ 14:07:
Cheatah, kan je uitleggen waarom sudo beter is dan groepslidmaatschap?

Niet per definitie, wel als je het goed gebruikt. Wat ik bedoel is dat je dat groeplidmaatschap verschuift naar een andere user dan www-data waardoor je via die weg de gebruiker www-data niet teveel rechten geeft. Het kan ook zonder extra user, maar ik vind met netter.

Sudo is bovendien niet altijd aanwezig (als je Debian installeert en je geeft een root wachtwoord op, krijg je geen sudo en moet je 'm later handmatig installeren).

Dat is geen argument in dit geval.

Daarnaast zijn er ook bepaalde beveiligingsrisico's met sudo. Bijvoorbeeld, het script wordt aangepast. Dan kan je alles als root doen, want dat ene script mag je als root uitvoeren, met alles wat erin staat.

Helemaal niet. In het ergste geval kan de gebruiker www-data alles uitvoeren als gebruiker die je hebt ingesteld in de sudoers configuratie.

CyBeR schreef op zaterdag 04 januari 2014 @ 14:49:
Inderdaad, sudo preventeert je dan wel een ander script uit te voeren maar dat script draait nog altijd als root en kan dus alles doen.

Als je opgeeft dat het script moet draaien als root wel ja. Maar moet opgeven dat het script mag draaien als je unprivileged user die lid is van de dialout groep.
Volgens mij moeten hier maar eens wat mensen meer gaan lezen over sudo.

code:

www-data ALL = (:dialout) NOPASSWD: /usr/local/bin/use-pyserial

sudo -g dialout /usr/local/bin/use-pyserial

Probleem opgelost. Je script kan door user www-data worden gerund met de dialout group. En www-data is geen lid van de dialout group. Uiteraard moet het script ook niet kunnen worden aangepast door www-data.

[Promy]

Ik blijf altijd verbaastd staan van de vele mogelijkheden in linux
Heb ondertussen de man van sudo eens goed doorgelezen en ik had inderdaad wat verkeerd geinterpreteerd. Het is ondertussen gelukt om het script te laten draaien door www-data!

[CyBeR]

Verwijderd schreef op zaterdag 04 januari 2014 @ 16:34:
[...]

Als je opgeeft dat het script moet draaien als root wel ja. Maar moet opgeven dat het script mag draaien als je unprivileged user die lid is van de dialout groep.
Volgens mij moeten hier maar eens wat mensen meer gaan lezen over sudo.

code:

www-data ALL = (:dialout) NOPASSWD: /usr/local/bin/use-pyserial

sudo -g dialout /usr/local/bin/use-pyserial

Probleem opgelost. Je script kan door user www-data worden gerund met de dialout group. En www-data is geen lid van de dialout group. Uiteraard moet het script ook niet kunnen worden aangepast door www-data.

Op die manier kan dat script, aangezien het draait met GID 'dialout', nog steeds bij al je seriele poorten. Je hebt dus niks bereikt behalve dat je het geheel complexer hebt gemaakt en je externe processen moet aanroepen.

[Wolfboy]

CyBeR schreef op zondag 05 januari 2014 @ 15:26:
[...]


Op die manier kan dat script, aangezien het draait met GID 'dialout', nog steeds bij al je seriele poorten. Je hebt dus niks bereikt behalve dat je het geheel complexer hebt gemaakt en je externe processen moet aanroepen.

Ehmm... leg dat eens uit?

Zolang het script niet schrijfbaar is door iemand anders dan root (of whatever, als het maar niet writable is) kan je op die manier perfect beperken dat userX commandoY kan uitvoeren als userZ zonder dat opeens alles uitgevoerd kan worden als userZ.

Persoonlijk zou ik voor de eenvoud hier ook gaan voor het toevoegen aan een groep, maar dat is meer omdat het eenvoudiger is.

Kwa veiligheid is de sudo oplossing een heel stuk veiliger (mits je script veilig is) dan alle andere voorgestelde oplossingen hier. Alternatief is een programma met suid bit natuurlijk een optie, maar ook dat is minder veilig dan sudo want daar staan in principe geen limitaties op wat betreft wie het script mag uitvoeren.

[CyBeR]

Wolfboy schreef op zondag 05 januari 2014 @ 15:43:
[...]
Ehmm... leg dat eens uit?

Zolang het script niet schrijfbaar is door iemand anders dan root (of whatever, als het maar niet writable is) kan je op die manier perfect beperken dat userX commandoY kan uitvoeren als userZ zonder dat opeens alles uitgevoerd kan worden als userZ.

Ja, maar die serial devices (/dev/ttyS*) hebben allemaal als gid 'dialout'. Dat script wat je uitvoert kan dus bij alle poorten, net als wanneer je www-data in de dialout groep zou gooien. De 'niet aanpassen voor www-data' truuk is in beide gevallen uit te halen natuurlijk, en in beide gevallen ga je er op dat moment vanuit dat je script feilloos is.

Kwa veiligheid is de sudo oplossing een heel stuk veiliger (mits je script veilig is) dan alle andere voorgestelde oplossingen hier. Alternatief is een programma met suid bit natuurlijk een optie, maar ook dat is minder veilig dan sudo want daar staan in principe geen limitaties op wat betreft wie het script mag uitvoeren.

Strict gezien is 't mischien ietsje veiliger omdat je tegen sudo kan zeggen dat alleen dat ene script uitgevoerd mag worden, maar zoals ik al zei is het ook complexer. Het is een afweging.