Discussion :

[mnemozip]

Bonjour,

Lors de l'ouverture du port USB avec ce type de commande par exemple.

fd = open (portname, O_RDWR | O_NOCTTY | O_SYNC, PERMS);

La valeur actuelle est S_IRWXU soit 700 en octale.

J'ai en retour sous Linux un code 13 : "acces denied"

Quel valeure doit-on donner a PERMS :

1/ Pour que le mot de passe utilisateur soit demandé pour ouvrir le port USB en "full acces" ?

ou

2/ Que l'acces au port USB soit libre et total ?!

Merci de votre aide

[Sve@r]

Bonjour

Quel valeure doit-on donner a PERMS :
1/ Pour que le mot de passe utilisateur soit demandé pour ouvrir le port en "full acces" ?

ou

2/ Que l'acces au port soit libre et total ?!

En dehors de cete histoire "d'ouverture de port" (un port c'est juste un numéro situé dans la trame tcp/ip, un peu l'équivalent d'un canal de communication sur un talkie, permettant à la trame d'être récupérée facilement par qui en a besoin et donc il ne "s'ouvre" pas !!!) je ne vois pas pourquoi l'utilisateur devrait donner son mot de passe pour ouvrir un truc appartenant à un autre (je présume root).

C'est vrai qu'il existe la commande sudo qui demande le mot de passe de l'utilisateur pour lui donner ensute les droits d'un autre mais cette commande, qui tourne sous root, est programmée en ce sens. Quand on l'invoque elle commence par vérifier l'identité de celui qui l'invoque avant de continuer en utilisant ses accès root pour alors récupérer les droits d'un autre et les donner à l'appelant. Donc tu peux programmer ton code de façon équivalente (demander un mot de passe et aller le comparer à celui stocké dans /etc/shadow). Avec bien entendu au final ton exécutable appartenant à root et avec un suid de positionné pour qu'il s'exécute avec les droits root. Ou alors tu peux lancer sudo ton_exec.

Ensuite la valeur donnée à perms est une valeur utilisée à la création du fichier. Si le fichier est créé, alors il sera créé avec les droits de "perms" (on dit plutôt "mode") mais s'il existe déjà, alors cette valeur n'est pas prise en compte. A la limite si ta question est "quelle valeur doit-on donner à perms pour que le fichier créé soit en accès libre et total" alors la réponse serait 777 (S_IRWXU|S_IRWXG|S_IRWXO). Parce que bien évidemment il n'y aurait aucune sécurité s'il suffisait de donner une valeur particulière à "perms" pour pouvoir accéder librement et totalement à n'importe quel fichier du système déjà existant.

Donc voilà. Peut-être devrais-tu d'abord te familiariser avec les processus et leur façon d'intéragir avec les droits des fichiers avant de vouloir coder système...

[mnemozip]

Le programme ne tourne pas sur un terminal, et encore moin avec un réseau.

C'est pour une communication série direct entre un ordi avec son OS ( quel qu’il soit ) et une carte électronique gérant une application en stand alone.

J'écris les 2 programmes s'échangeant des informations.

Donc, lors de l'ouverture avec OPEN, j'aimerai que le mot de passe utilisateur soit demandé pour obtenir l'accès en R/W a /dev/ttyUSB0 comme dans l'application MINICOM.

J'ai le source et j'essaie de trouver l'information mais pour gagner du temps je demande sur le Forum.

Merci

[Sve@r]

Donc, lors de l'ouverture avec OPEN, j'aimerai que le mot de passe utilisateur soit demandé pour obtenir l'accès en R/W a /dev/ttyUSB0

Sous Unix, un processus n'a aucun droit, aucun accès. Ce sont les fichiers qui ont des droits d'accès. Un processus, lui, il n'a que deux identifiants: un uid (n° d'utilisateur) et un gid (n° de groupe), uid et gid hérités du uid et gid de celui qui lance le programme. Un fichier lui possède aussi un uid+gid (hérités de celui qui a créé le fichier) et 3 groupes de droits rwx, le premier associé au uid (u), le second associé au gid (g) et le 3° associé à tous les autres (others=o) => droits ugo.
Dès lors, dès qu'un processus quel qu'il soit tente d'accéder à un fichier quel qu'il soit, le noyau Unix possède à une vérification

• si le uid du processus = uid du fichier, ce seront les droits "u" (et seulement u) qui seront évalués. Et si ces droits permettent la lecture alors le procesus pourra lire le fichier, s'ils permettent l'écriture alors le procesus pourra écrire dans le fichier, et s'ils permettent l'exécution alors le processus pourra "exécuter" le fichier (le sens de "exécuter" dépendant alors de la nature du fichier). Sinon tant pis, le processus se verra interdire l'accès (et ce, même si les droits "go" eux l'autorisent !!!)
• sinon alors si gid processus = gid du fichier, ce seront les droits "g" (et seulement g) qui seront évalués. Et de même si ces droits permettent la lecture alors ... etc.
• sinon ce seront les droits "o" qui seront évalués. Et là encore si ces droits permettent la lecture alors ... etc.

Donc de là, aucun processus quel qu'il soit ne peut obtenir des droits sur un fichier si le fichier n'a pas déjà positionné ces droits. C'est pour ça qu'on dit qu'un système Unix est insensible aux virus car un virus c'est avant tout un exécutable et que cet exécutable sera soumis aux mêmes lois. Attention, ce n'est pas parce que le système est insensible aux virus que les fichiers persos de l'utilisateurs le sont => rien n'empêche un petit malin de créer un programme quelconque qui, s'il est lancé par un utilisateur, ira lui pourrir tous ses fichiers persos, ses photos, sa comptabilité, etc. Cela n'entre absolument pas en contradiction avec la façon qu'a Unix de gérer les accès car le programme (le virus) lancé par l'utilisateur aura alors le uid+gid dudit utilisateur et pourra donc accéder aux fichiers de l'utilisateur.

A ces droits élémentaires se rajoutent deux options => le setuid et le setgid (en fait il y en a 3 car il y a aussi le sticky bit mais lui il a un autre rôle donc je n'en parle pas)
Un processus c'est d'abord un programme (un exécutable qui est aussi un fichier). Je lance "ls" je vais alors exécuter le programme "/bin/ls" qui est aussi un fichier. Par défaut, un processus hérite du uid+gid de l'user qui exécute le programme. Mais le programme (le fichier) possède lui-aussi un uid+gid. Génralement ce uid+gid n'ont aucune importance pour le processus généré car le processus hérite des uid+gid de l'user et le uid+gid du programme ne sont pas pris en compte.
Sauf si le setuid est positionné sur le programme (le fichier). Dans ce cas précis, alors le processus issu du programme n'héritera pas du uid de l'user qui appelle ce programme mais du uid du programme lui-même. Et il en va de même si le setgid est positionné, le processus issu du programme héritera du gid du programme lui-même. Ca ne change rien au mécanisme de contrôle quand le processus tente d'accéder à un fichier quelconque, sauf que les uid/gid contrôlés seront ceux du programme et non de l'utilisateur. C'est gràce à ce mécanisme que le programme /bin/passwd a tout pouvoir pour modifier le fichier des mots de passe "/etc/shadow".

Tout ça pour dire qu'aucun programme ne pourra accéder de lui-même à un fichier si les droits du fichier ne l'autorisent pas déjà. Y compris /dev/ttyUSB0. Si toi tu n'y as pas accès, alors aucun programme que tu exécuteras n'y aura accès. Sauf si l'admin de ta machine (root) s'arrange pour que le programme (le fichier exécutable) ait un uid/gid correspondant à celui de /dev/ttyUSB0 et positionne le setuid du programme (du fichier exécutable) pour que tout processus issu de ce programme (ce fichier exécutable) ait son uid/gid compatible avec le uid/gid + les droits de /dev/ttyUSB0. Généralement seul le uid root convient (lui il a tous les droits) donc généralement l'admin place l'exécutable avec uid root puis positionne le setuid de l'exécutable.

comme dans l'application MINICOM

Je ne connais pas MINICOM mais si elle tourne sous un Unixlike, elle ne peut que obéir à ses lois. Si elle doit accéder à un fichier quelconque, elle ne peut le faire que si les droits du fichier sont compatibles avec le user qui l'exécute, ou alors si elle a un setuid/setgid de positionné.

Le programme ne tourne pas sur un terminal, et encore moin avec un réseau.

Ouais, il tourne en virtuel quoi...

[mnemozip]

Non, justement rien de virtuel. On travail sur les port physique du PC.

Merci pour les informations.

Si j'ai bien compris. Dans un terminal, je passe en super-utilisateur puis ensuite je lance l'application qui accède à la ressource réel.

Ou alors, je rajoute dans le code C, un accès fichier qui engendrera une demande de mot de passe et par héritage, l'application pourra accéder aux ressources physique.

J'essaie en rentrant ce soir car en présentiel et suis sous W10 et donc cela me fait travailler le côté multi architecture. Avec cet OS, mon appli fonctionner devrait-elle

[Sve@r]

Si j'ai bien compris. Dans un terminal, je passe en super-utilisateur puis ensuite je lance l'application qui accède à la ressource réel.

Oui. Ou alors tu lances l'instruction sudo programme qui permet de lancer le programme sous le compte d'un autre user (root par défaut).

Ou alors, je rajoute dans le code C, un accès fichier qui engendrera une demande de mot de passe et par héritage, l'application pourra accéder aux ressources physique.

La demande de mot de passe ne donne aucun droit, elle permet juste de t'assurer que celui qui exécute l'application est bien autorisé à l'exécuter. Il reste incontournable que si ton appli doit avoir accès à une ressource qui ne t'appartient pas, elle doit alors tourner sous un compte qui lui a accès à la ressource donc qu'elle possède un setuit ou un setgid. Ou alors qu'elle passe par sudo.

Avec cet OS, mon appli fonctionner devrait-elle

W10 c'est totalement différent. Pour simplifier le souci des droits, les concepteurs de W10 mettent tout le monde en admin par défaut. Fatalement ils ont tous les droits donc oui ton appli aura accès à tout. Accessoirement c'est aussi la raison principale pour laquelle les virus sont si prolifiques sur cet OS. Pour eux, l'accès au système c'est open bar !!!

[mnemozip]

C'est pour cela que j'utilise personnellement Linux, occasionnellement Windows.

Mais au boulot, je n'ai pas de station Linux "officiellement"

J'utilise un Live a l'occasion sur une de mes machines afin de bidouiller !

Merci pour les précisions.

Je continu mes recherches et je transmet les info dès que c'est résolu.

Si elles apparaissent sur ce post, mille merci.

[Sve@r]

Mais au boulot, je n'ai pas de station Linux "officiellement"... J'utilise un Live a l'occasion sur une de mes machines afin de bidouiller !

Tu devrais aller regarder du côté de VirtualBox...

[Médinoc]

W10 c'est totalement différent. Pour simplifier le souci des droits, les concepteurs de W10 mettent tout le monde en admin par défaut. Fatalement ils ont tous les droits donc oui ton appli aura accès à tout. Accessoirement c'est aussi la raison principale pour laquelle les virus sont si prolifiques sur cet OS. Pour eux, l'accès au système c'est open bar !!!

C'est plus censé être le cas depuis au moins Vista, ça...
Mais entre "censé" et la réalité il y a une marge, en effet. Je me souviens de jeux repackagés pour lesquels la "correction" du problème des sauvegardes dans le dossier d'install a été de flagguer le jeu comme devant tourner en Admin...

[mnemozip]

Bonjour,

Afin de palier au problème de droit d’accès à un port série dans une application 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.

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

Si vous avez de quoi m'aider je reste à l'écoute.

Merci.

PS : J'ai mis un autre post traitant du même sujet sur le forum, mais pas dans "débutant"...