Acces gpio sur raspberry/debian
Résolu/Fermé
archi12
Messages postés
26
Date d'inscription
lundi 13 février 2006
Statut
Membre
Dernière intervention
26 mai 2016
-
Modifié par archi12 le 4/04/2016 à 15:05
mamiemando Messages postés 33372 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 22 novembre 2024 - 8 avril 2016 à 16:14
mamiemando Messages postés 33372 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 22 novembre 2024 - 8 avril 2016 à 16:14
A voir également:
- Acces gpio sur raspberry/debian
- Acces rapide - Guide
- Accès refusé - Guide
- Pourquoi google me bloque l'accès de certain sites ? - Guide
- Clé d'accès google - Accueil - Guide confidentialité
- Comment autoriser l'accès au stockage android - Guide
3 réponses
mamiemando
Messages postés
33372
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
22 novembre 2024
7 802
7 avril 2016 à 10:45
7 avril 2016 à 10:45
Bonjour :
1) Il faut devenir root, car seul lui peut écrire dans ce fichier :
2)a) La méthode la plus propre reste quand même d'autoriser l'utilisateur concerné à être sudoer sur cette commande :
https://stackoverflow.com/questions/583216/run-a-linux-system-command-as-a-superuser-using-a-python-script
2)b) Une autre solution consiste à activer le bit set-uid sur ton script python, un peu à l'image de ce qui est fait avec des commandes comme
https://fr.wikipedia.org/wiki/Setuid
Par contre je déconseille cette méthode car si un utilisateur malveillant altère ce script, il est virtuellement root. En particulier seul root devrait alors pouvoir corriger ce script :
À toutes fins utiles, quelques rappels sur les droits linux :
https://www.mistra.fr/tutoriel-linux-profils-et-droits.html
Bonne chance
1) Il faut devenir root, car seul lui peut écrire dans ce fichier :
(mando@velvet) (~) $ ls -l /sys/class/gpio/export
--w------- 1 root root 4096 avril 7 09:56 /sys/class/gpio/export
2)a) La méthode la plus propre reste quand même d'autoriser l'utilisateur concerné à être sudoer sur cette commande :
https://stackoverflow.com/questions/583216/run-a-linux-system-command-as-a-superuser-using-a-python-script
2)b) Une autre solution consiste à activer le bit set-uid sur ton script python, un peu à l'image de ce qui est fait avec des commandes comme
passwdou
usermod(qui quand on y réfléchit, sont des commandes pouvant être exécutées par un utilisateur et capable de modifier un fichier appartenant à root, typiquement /etc/passwd). C'est notamment évoqué dans le lien ci-dessus mais ça peut être réalisé simplement avec un
chmod.
https://fr.wikipedia.org/wiki/Setuid
chown root script.py
chmod u+s toto.py
Par contre je déconseille cette méthode car si un utilisateur malveillant altère ce script, il est virtuellement root. En particulier seul root devrait alors pouvoir corriger ce script :
chown g-w script.py
chown o-w script.py
À toutes fins utiles, quelques rappels sur les droits linux :
https://www.mistra.fr/tutoriel-linux-profils-et-droits.html
Bonne chance
archi12
Messages postés
26
Date d'inscription
lundi 13 février 2006
Statut
Membre
Dernière intervention
26 mai 2016
7 avril 2016 à 17:52
7 avril 2016 à 17:52
mamiemando,
tres bonnes explications.
le pb a ete resolu d'une facon (peut etre pas tres orthodoxe) en mettant
echo 17 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio17/direction
directement dans rc.local
et en ne gardant que
echo 1 > /sys/class/gpio/value
dans le prog en C
mais ca marche !
merci encore
tres bonnes explications.
le pb a ete resolu d'une facon (peut etre pas tres orthodoxe) en mettant
echo 17 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio17/direction
directement dans rc.local
et en ne gardant que
echo 1 > /sys/class/gpio/value
dans le prog en C
mais ca marche !
merci encore
mamiemando
Messages postés
33372
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
22 novembre 2024
7 802
8 avril 2016 à 16:14
8 avril 2016 à 16:14
Merci pour ton retour, effectivement comme /etc/rc.local est exécuté en root ça doit débloquer partiellement la situation.
En fait, la vraie question, c'est le rôle que tu veux donner à ton programme C :
1) soit il doit tout faire comme un grand, mais il va nécessiter des droits root ;
2) soit pouvoir être lancé par un utilisateur, mais il va nécessiter que le système est "dans de bonnes conditions").
Si tu es dans le cas (2), il faut se demander s'il est légitime que les commandes lancées au démarrage sont légitimes pour tous tes utilisateurs de la machine, et activée systématiquement quand la machine est démarré. En effet sous linux, un utilisateur n'a le contrôle que sur ce qui le concerne lui seul, et tout ce qui peut nuire à un autre utilisateur que toi ne peut être fait qu'en root.
1) si c'est le cas ta solution "peu orthodoxe" reste acceptable
2) si ce n'est pas le cas, il serait pas mal que ton utilisateur soit sudoer sur un script permettant d'exécuter ces deux commandes avant de lancer le programme C.
Bonne chance et bonne continuation !
En fait, la vraie question, c'est le rôle que tu veux donner à ton programme C :
1) soit il doit tout faire comme un grand, mais il va nécessiter des droits root ;
2) soit pouvoir être lancé par un utilisateur, mais il va nécessiter que le système est "dans de bonnes conditions").
Si tu es dans le cas (2), il faut se demander s'il est légitime que les commandes lancées au démarrage sont légitimes pour tous tes utilisateurs de la machine, et activée systématiquement quand la machine est démarré. En effet sous linux, un utilisateur n'a le contrôle que sur ce qui le concerne lui seul, et tout ce qui peut nuire à un autre utilisateur que toi ne peut être fait qu'en root.
1) si c'est le cas ta solution "peu orthodoxe" reste acceptable
2) si ce n'est pas le cas, il serait pas mal que ton utilisateur soit sudoer sur un script permettant d'exécuter ces deux commandes avant de lancer le programme C.
Bonne chance et bonne continuation !