Discussion :

[mnemozip]

(Ndlm : message initialement posté à la suite de cette discussion).


Bonjour, je répond un moment après son post mais je suis confronté au même besoin.

L'accès au port retourne une erreur 13 : "Permission denied" !

Pour accéder au port avec succès sous Linux il faut insérer "une demande de droit d'accès" ce qui correspond a saisir le mot de passe utilisateur ou superutilisateur.

Avez vous une idée comment le faire ?

Merci de votre aide.

[Obsidian]

Bonjour,

Bonjour, je répond un moment après son post mais je suis confronté au même besoin.

Presque dix ans plus tard, en effet. ;-)

L'accès au port retourne une erreur 13 : "Permission denied" !
Pour accéder au port avec succès sous Linux il faut insérer "une demande de droit d'accès" ce qui correspond a saisir le mot de passe utilisateur ou superutilisateur.

Non, ça c'est souvent ce que l'on fait en Shell quand on veut ponctuellement contourner le problème mais ce n'est pas en soi la première voie à suivre. Si tu obtiens « permission denied » en accédant à un fichier spécial, cela veut dire qu'il y a effectivement des droits d'accès dessus à respecter mais ce n'est pas à ton programme de les contourner : c'est à toi d'en faire la demande auprès de ton administrateur (si tu n'es pas toi-même l'administrateur de la machine sur laquelle tu travailles) ou de configurer les droits pour y avoir accès en conditions normales.

Lance un ls -l <chemin d'accès vers le fichier /dev/ concerné> et regarde quels sont ses droits. Tu peux les changer une fois pour toutes mais il y a de fortes chances pour qu'il appartiennent déjà à un groupe particulier. La méthode orthodoxe consiste alors à t'ajouter toi-même à ce groupe, puis te déconnecter/reconnecter pour que cela soit pris en compte. Tu auras alors le droit d'y accéder avec n'importe quelle commande ou programme, y compris celui que tu as écrit.

[mnemozip]

Merci pour les informations mais j'aimerai que mon programme se comporte comme l'application Minicom :

Lors de l’accès au /dev/ttyUSB0 que le mot de passe utilisateur soit demandé ?

[Obsidian]

Merci pour les informations mais j'aimerai que mon programme se comporte comme l'application Minicom :

Lors de l’accès au /dev/ttyUSB0 que le mot de passe utilisateur soit demandé ?

Lorsque j'essaie moi-même (avec le port série car je n'ai pas de terminal USB sous la main), j'obtiens bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ minicom -D /dev/ttyS1
Cannot create lockfile for /dev/ttyS1: Permission non accordée

Il faudrait que tu nous donnes plus de détails sur la distribution que tu utilises ainsi que la façon dont minicom t'invite à saisir ton mot de passe. Est-ce dans une fenêtre plein écran intégré à ton environnement de bureau ou est-ce depuis le terminal, depuis une ligne qui suit la commande que tu as lancée ?

Dans le premier cas, il est possible que ta distribution soit configurée pour placer des hooks sur certaines commandes utiles et/ou populaires (par exemple, « systemctl »), afin de t'inviter elle-même à saisir ton mot de passe et lancer ensuite la commande avec les droits, de façon à ce que cela apparaisse propre et facile à utiliser à l'utilisateur débutant.

Dans le second, il y a deux cas à prendre en compte. Le fait d'utiliser son mot de passe pour lancer l'application en super-utilisateur (généralement, sous Unix, tout cela s'appuie sur sudo) et le fait que minicom servent à exploiter une ligne série et se connecter à distance. Auquel cas, selon le protocole, le mot de passe demandé peut-être celui de la machine contactée et pas forcément la tienne.

Dans cette situation, ça ne te dirait pas comment minicom a pu avoir accès à la ligne série. La réponse est généralement dans les « setuid/setgid bits ». Un examen des bits de flags en début de ligne de ls -l $(which minicom) devrait te renseigner.

Dans tous les cas, il s'agit donc d'administration système avant d'être du langage C.

Je t'invite donc à jeter aux man pages suivantes pour te renseigner sur le fonctionnement des programmes que tu utilises

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
man su
man sudo
man sudoers
man minicom

… puis dans le cas de Minicom en particulier, aux fichiers de configuration qu'il utilise. Sur ta machine, certains sont peut-être déjà configurés sans que tu le saches pour gérer ces affaires de mot de passe :

FICHIERS
       Minicom conserve les fichiers de configuration dans un répertoire, habituellement /var/lib/minicom, /usr/local/etc ou /etc. Pour chercher quel répertoire par défaut est com‐
       pilé, faites la commande minicom -h. Vous trouverez probablement aussi les fichiers de démonstration pour runscript(1), et les exemples de tables de conversion de caractères
       soit  ici, soit dans les sous-répertoires de /usr/doc/minicom*. Les tables de conversion sont nommées quelque chose comme mc.* dans ce répertoire, mais vous voulez probable‐
       ment copier ceux dont vous avez besoin dans votre dossier personnel en quelque chose commençant par un point.

       minicom.users
       minirc.*
       $HOME/.minirc.*
       $HOME/.dialdir
       $HOME/minicom.log
       /usr/share/locale/*/LC_MESSAGES/minicom.mo

Bon courage.

[mnemozip]

Oui, j'ai le source et je recherche les informations... mais en attendant j'ai mis un post pour essayer de gagner du temps pensant que la solution serait dégainée rapidement


Je dispose de plusieurs pc sous des Linux différents, un W8 et un W10.

Au boulot un w10.

Je travaille aussi le faite que mon appli peut être compilée sous différents OS.

Merci

[mnemozip]

Bonjour,

J'ai effectué les manipes proposées mais l’accès reste interdit.

Afin de palier au problème de droit d’accès à un port série dans une application en C qui tourne sous Linux.

Il faut faire une demande au system.

J'ai le code source de l'application Minicom et donc, j'ai bien vu les manipulations.

De faire des copier coller du source, ne sert a rien car les informations nécessaires sont réparties dans différents librairies.

Il faut intégrer dans le code C, les librairies nécessaire pour accéder via des sockets au system.

Via les sockets, le programme effectue une commande qui en retour sur le terminale demande à l'utilisateur le mot de passe pour obtenir les droits.

Si OK, l'ouverture port avec la commande OPEN ne retourne pas -1.

Si quelqu'un peux m'expliquer le principe et m'orienter vers un source que je pourrai adapter à mon application cela me serait très utile.

Merci par avance.

[disedorgue]

Le principe sous linux/unix, c'est que ton programme soit executé en tant que super user (root).
2 solutions:
THE VERY BAD SOLUTION:
Ton programme une fois compilé, le faire appartenir à root (chown), lui mettre un setuid (chmod) et là, quand il s'execute, il prend les droit root, donc c'est à lui de vérifier que tout va bien, que l'utilisateur est habilité,blabla...
Ce qui est une très mauvaise solution.

Meilleur solution:
Tu compiles ton programme, qui ne s'occupe pas du tout de la partie acces, et ceux qui en ont besoin, l'execute via sudo et là les habilitations se font via sudo et non ton programme.
Lit le man de sudo pour voir les options possible de celui-ci si tu veux que cela soit graphique.

[mnemozip]

Bonjour,

J'ai crée un projet "terminal" qui une fois compilé indique une erreur sous l'environnement de développement.

Lorsque je lance l’exécutable dans un "terminal", j'ai aussi un retour d'erreur !

L'erreur provient d'un accès au port série /dev/ttyUSB0.

J'ai saisie les commandes suivantes :

chmod 770 /dev/ttyUSB0 pour les droits d'accès en lecture/écriture.

sudo usermod -a <user> -G dialout pour être autorisé à accéder au port série.

ls /dev/ -l pour vérifier.

Lorsque je passe en mode super utilisateur et que je lance l’exécutable, pas d'erreur je peux continuer.

Merci

[Obsidian]

C'est pas mal du tout. C'est effectivement comme ça qu'il faut faire, à condition de bien s'assurer aussi que /dev/ttyUSB0 appartienne bien au groupe dialout !

Si c'est un autre groupe et que c'est le système qui l'a défini, alors — tant que ce n'est pas le groupe root — il vaut mieux t'ajouter toi-même dans ce groupe plutôt que modifier celui du fichier spécial.

En outre, lorsque tu intègres un utilisateur (toi) à un groupe, il faut que l'utilisateur concerné referme et réouvre sa session pour qu'il soit pris en compte. En principe, fermer le shell ou lancer un sous-shell en mode login suffit, mais comme on travaille tous aujourd'hui depuis une session graphique sous Xorg qui, elle-même, hérite de la session ouverte au préalable, le plus simple reste de se déconnecter/reconnecter.

[mnemozip]

Merci,

Maintenant, je passe à la suite et donc sur un autre post :

Mettre en place 3 séquences en parallèle.

- Une lecture clavier non bloquante.
- Un lecture du port série : récepteur plein ou erreur de réception (break, etc)
- Un gestion du temps pour les timout.

donc, a bientôt.

[Obsidian]

- Une lecture clavier non bloquante.
- Un lecture du port série : récepteur plein ou erreur de réception (break, etc)
- Un gestion du temps pour les timout.

Pour ces trois choses, tu auras besoin de select(), et éventuellement de poll(). Si tu développes bien en C, bien sûr.

[mnemozip]

Afin de pouvoir obtenir une certaine indépendance voir de liberté pour chaque process, je regarde ce que les THREADS pourraient m'apporter.

De plus, par le biais de la norme POSIX on aurai de la portabilité entre les OS, ce qui éviterait de tout refaire en double !

Je reprend le cours du post, mais en ce moment j'essaie cette méthode.

Qu'en pensez-vous ?

Merci

[Obsidian]

Afin de pouvoir obtenir une certaine indépendance voir de liberté pour chaque process, je regarde ce que les THREADS pourraient m'apporter.

C'est une très bonne chose mais ça apporte son lot de problème aussi. Le traitement en parallèle, le multitasking et les accès concurrents sont des joyeusetés à déboguer.

C'est une approche qui est très répandue, mais il faut aussi apprendre à faire sans, ne serait-ce que d'un point de vue algorithmique. Les ordinateurs n'ont pas toujours été multitâches… S'attacher à écrire un petit serveur IRC fonctionnant en un seul processus, par exemple, permet à la fois de converger naturellement vers le concept de boucle principale et d'identifier les seules ressources système externes à son propre programme dont on pourrait avoir besoin. Lesquelles se résument en fait à select().

On utilise généralement des threads soit quand on a une interface graphique, qui passe également son temps à attendre, mais qui doit être réactive quand l'utilisateur la sollicite, ne serait-ce que pour indiquer que son action a bien été prise en compte même si elle est traitée en différé, soit lorsque les tâches clientes deviennent suffisamment compliquées pour ressembler au lancement en parallèle d'une application donnée.

De plus, par le biais de la norme POSIX on aurai de la portabilité entre les OS, ce qui éviterait de tout refaire en double !

select() est POSIX également.