La fonction de recherche opère de la même manière que dans un traitement de texte. Elle localise dans l'ensemble visualisé, les éléments qui répondent au critère et te permet de naviguer d'un élément à l'autre. Pour autant, tous les éléments sont visibles.
Ce que je voudrais, c'est ne voir que les éléments répondants à mes critères d'affichage.
Peut-on vouloir le beurre et l'argent du beurre ?
Il faudrait pouvoir coupler ces mécaniques de sécurité Wayland avec les systèmes déjà existants : SElinux, AppArmor, … de sorte notamment, qu'il ne faille pas redéclarer à chaque fois les mêmes autorisations.
D'abord il me confirme la vision que j'ai de Wayland et du fonctionnement attendu d'une application de capture d'écran :
This keeps the user in control of the process: the user is informed that a screenshot is being taken and informed how to cancel this. This addresses the security concerns we had for taking screenshots. By making the user perform an explicit action we know that the user agreed to taking the screenshot.
Mais il va de soi que l'article qui a été rédigé fin 2016, n'est pas d'actualité : j'ai fait l'essai hier de lancer Plama/Wayland (Debian Buster) et de faire une capture de l'intégralité de l'écran. Aucune confirmation ne m'a été demandée !!!
En fait si, je me suis merdé : une action utilisateur est bien réclamée; une vignette est affichée pour demander à l'utilisateur de confirmer ou d'annuler l'opération ! Super ! Mais tout n'est pas clair pour autant :
Scénario "a" :
1) Spectacle : ok, je veux faire la capture de l'écran, et l'utilisateur m'a donné son accord.
2) Wayland : Ah. Bon ben, s'il est ok, je suis ok.
Scénario "b" :
1) Malware : ok, je veux faire la capture de l'écran, et l'utilisateur m'a donné son accord (mensonge).
2) Wayland : Ah. Bon ben, s'il est ok, je suis ok.
Alors évidemment, je pense qu'il manque des étapes et des composants, et que tout cela n'est pas aussi simple. J'entrevois même une complexité affolante !
Effectivement, tant que le service NetNSAdm (celui qu'il nous faut écrire) n'a pas démarré, il faut qu'aucune application n'est droit d'accès au réseau !
Dans le man de "ip netns" il est dit :
By default a process inherits its network namespace from its parent. Initially all the processes share the same default network namespace from the init process.
Voici ce à quoi j'ai pensé. Proposez-moi mieux, plus simple, de déjà existant… Partagez vos idées !
Au lancement du service (qu'il nous faut écrire ;) :
- changer netns de tous les processus ayant un exe dans leur proc pour NONET (aucune interface déclarée)
- création de tous les netns nécessaires pour la configuration
- appliquer la configuration avec un processus de surveillance :
Fichier de configuration :
# création des alias interfacealias <aliasif name> <interface>
# affection des ns aux groupes d'applications
grp [<parent grp name>:[<parent grp name>:[..]]]<grp name> <exe path> \[+<checker function> [+<checker function> [..]]]\[<aliasif name> [<aliasif name> [..]]]|IDEM \[LOCKDOWN]
Exemple :
aliaslocal enp3s0
alias net eno1
grp Ping /bin/ping local net
grp Eclipse /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java +checkEclipse local
grp Eclipse:Python3 /usr/bin/python3 local net
grp Eclipse:Python3:* * local
Le processus de surveillance réalise les opérations suivantes (ttes les n secondes) :
liste l'ensemble des processus en cours :
si le processus considéré est déjà enregistré alors ne fait rien.
sinon enregistre le processus :
recherche dans /proc/<pid>/exe et s'il le trouve récupère le chemin pointé (ex : /usr/bin/python3)
recherche dans les chemins en conf une correspondance non bloquée (bloquée = LOCKDOWN) et validée (tous les routines de vérification sont satisfaites comme +checkEclipse dans l'exemple) (ex : -> Eclipse:Python3)
la chaine des parents doit être reconstruite (ex : le processus Python possède-t-il comme parent Eclipse ? ie le PPID du processus Python appartient-il au groupe Eclipse ?)
si non, alors on ne fait rien de plus
si oui, alors on poursuit ainsi de suite jusqu'au premier parent. Si c'est le dernier parent qui a été considéré alors :
on déplace le processus Python dans le netns correspondant.
Si parmi la liste des processus enregistrés certains n'existent plus, alors ils sont retirés de la liste.
Je ne connais pas SELinux. Un peu plus AppArmor… Dans mon exemple je parle d'Eclipse, application pour laquelle je voulais interdire tout accès au net. J'ai dû écrire un profil AppArmor pour cela… Pour moi, c'est vraiment trop compliqué. Alors que le besoin est simple !
Maintenant, pour le cas d'Eclipse, je ne passe plus par AA. Mais bien par la commande "ip netns exec". Je pense que la solution passe par cette commande. Je creuse…
Tu parles des accès disques. Les systèmes de fichiers offrent des protections pour les sécuriser.
Pourquoi rien n'existe avec X ?
J'ai trouvé aussi ça, qui va dans le sens de tout ce que vous dites : wayland-vs-xorg
Un passage intéressant :
Issues with the Xorg
As discussed above, the design of the Xorg doesn't allow the applications to have GUI-Level isolation. This implies that if the system has multiple GUI applications running, like Word Office, any of your favourite editor, or something else, then there is no isolation among them. It is easy to log keystrokes of all processes of the same user using the command xinput.
The command generates the log of all key-presses. Any kind of isolation is not possible, even using SELinux since any keystrokes passed to the X Server are available for any arbitrary program.
La démonstration qui est faite dans la suite de l'article, avec xinput et sudo (mais ça marche évidemment avec tout) est saisissante, vertigineuse. xev fait aussi le job.
Et après on nous bassine sur l'utilité de choisir de bons mots de passe, sur la performance de tel ou tel technologie de cryptage, sur l'isolation par conteneur… mais que valent tout ça quand le système est pourri à la base ?
Il reste plusieurs solutions, que vous avez suggérées, en agissant, non pas sur la capture d'informations périphériques E/S, mais en agissant sur la capacité que peut avoir une application à communiquer avec le monde extérieur "malveillant" partant du principe, maintenant, qu'elle a accès à tout, en tout cas à l'essentiel :
- se déconnecter du monde
- isoler du réseau toutes les applications qui ne devraient pas en avoir usage; là SELinux ou AppArmor restent encore efficaces.
- passer en mode console, en changeant d'utilisateur (=> avec des droits restreints), pour surfer, télécharger, jouer,… :(
Bref, c'est mission impossible !
Heureusement, on peut quand même compter sur l'accès au code source, sur les très mauvaises retombées médiatiques qui frapperaient tous concepteurs d'applications malicieux s’adonnant à l'espionnage mais découverts… ;)
Pour information, c'est également le cas pour d'autres OS connus, tel MS-Windows.
MS-Windows n'est pas mon problème. Je laisse le SI de ma boîte se débrouiller avec ça. Chez moi, c'est Linux le problème ;)
Avec Wayland, c'est simple, c'est exactement l'inverse…
Super ! Bon je vais bien me rencarder sur le sujet. Même si cela semble poser des problèmes au fonctionnement de Steam… Tiens donc…
Anecdote au passage : je fais tourner Steam dans un conteneur Lxc. Dans ce conteneur j'avais également Firefox installé. Saviez-vous que celui-ci démarre en mode "Remote" par défaut ? Cela donne accès à tout ce qui est vu de processus Firefox parent, celui là même qui est lancé depuis la machine hôte (en dehors du conteneur). Ben voyons ! C'est open bar !
Tout cela semble bien exact. Et inquiétant. Le "système" semble tellement contenir de failles que je me demande si on n'est pas dans l'erreur. Ce doit être plus compliqué que ça… Car si faille il y a, alors elle est sans doute exploitées.
Donc si je comprends bien, n'importe quel logiciel GUI en cours d'exécution, a la possibilité de faire la capture de tout l'écran sans qu'il en ait à répondre à personne ?
Alors avec Wayland, sais-tu, savez-vous, si des mécanismes d'autorisations ont été prévu ? Quels en sont les principes ?
Par exemple, est-il possible d'indiquer que les ressources graphiques (fenêtres) de tel processus ou groupe de processus sont accessibles ou non pour d'autres processus du système ?
Par exemple, me serait-il possible de configurer le système, pour que par défaut, tout processus ne puisse utiliser uniquement SES ressources visuelles ?
Quand je lance mon trousseau KeepassX je serais vachement plus serein si j'avais la certitude qu'au moment où je visualise un mot de passe généré, en clair, celui-ci n'ait pas été capturé par je ne sais quelle autre application malveillante.
C'est moi, ou cette absence de sécurité sur les contenus visuels semble préoccuper personne ? Dit autrement, je m'inquiète pour rien ?
Quand je parle d'interdire l'accès à l'affichage d'une application, je me suis mal exprimé, je voulais dire empêcher toute autre application d'accéder au contenu des fenêtres de cette application.
Oui. C'est exact ! Merci ! Je suis allé trop vite, et j'avais finalement rien compris!
Le tuto en question est ici.
Le cas qui me pose problème (l'application à auditer est lancer en root) c'est celui là : «processus à durée limitée».
Mais pour moi qui voulait faire l'audit d'Eclipse, j'aurais dû d'avantage m'intéresser à celui-ci : «processus de type daemon» qui ne pose aucun problème de sécurité puisque jamais l'application à auditer ne doit être lancée en super-utilisateur.
En effet, pour réaliser l'audit de l'application Eclipse :
> # 1) on créé un profil pour Eclipse (NB : eclipse est dans le PATH)
> sudo aa-autodep eclipse
> # 2) on lance l'application à auditer
> eclipse &
> # *) on fait faire l'audit régulièrement, à mesure des nouvelles fonctionnalités
> # utilisées, sans besoin de quitter Eclipse
> sudo aa-logprof
> # 4) Quand on considère l'audit terminé, on quitte Eclipse, et on active/impose le profil eclipse
> sudo aa-enforce eclipse
Le problème n'est pas celui des outils AppArmor me semble t-il, mais celui de devoir lancer l'application à auditer en tant que root.
Pour réaliser l'audit d'Eclipse, il m'est demander de faire :
Pour les autres (les jeux commerciaux) je me suis acheté une console.
- je n'ai plus de double boot sur ma machine mais uniquement du Linux.
- je ne file plus un radis à Micro-mes-c...es. Bon je ne suis pas certain que dans l'esprit Sony soit meilleur mais bon... c'est pas pareil...
- pas de soft proprio sur ma machine!
- et j'anticipe une remarque : au niveau prix c'est similaire. Le prix des jeux, si l'on n'est pas pressé, tombe au environ de 30 euros au bout d'un an après leur sortie. Le prix de la console est équivalent à celui que m'aurait coutait l'upgrade matérielle pour avoir l'équivalent sur PC (là mon PC je peux espérer le conserver en l'état... très longtemps).
- il n'empêche : j'adore Battle of Wesnoth.
Non effectivement, la problématique que je vous ai soumise ne me concerne qu'à titre personnel, mais peut intéresser les curieux... j'espère au passage que le "salope" n'aura choqué personne, même pas Asgeir...
Il est possible, je n'ai pas fait mais j'en suis aussi convaincu, d'écrire (même en bash) un programme de démarrage et de surveillance qui :
- à son lancement, démarre l'application indiquée
- envoie dans le pipe désigné un "signal" dès que l'application se termine
avantage :
- l'application est un processus enfant du shell => le programme peut utiliser un wait
- le programme "client" qui veut être informé peut se mettre en attente d'un evt sur le pipe sans consommer de CPU (lecture synchrone)/
inconvénient :
- pour l'instant, seul un/le client peut être informé de la terminaison de l'application
- c'est dingue (je trouve) d'en arriver là. Le besoin me parait simple et légitime. Mais bon je ne prétendrait pas avoir exploré toutes les solutions...
les problèmes de la scrutation périodique :
1/ si la vérification a lieu toutes les secondes, il peut dans le pire cas se passer une seconde entre la terminaison du processus et le moment où elle est détectée
2/ le process de surveillance consomme du CPU inutilement (d'autant plus que la période de scrutation est courte)
Pour cela je trouve la solution suggérée par 'rb14' plus intéressante (le coup du strace). J'attends une solution qui mette en oeuvre une spécificité du noyau (sorte de wait). peut être que je jetterai un œil sur le code du strace.
je cherche à savoir comment m'y prendre pour attendre la terminaison d'un processus, sachant que ce processus n'est pas un processus enfant (fils) du shell où je veut faire l'attente.
dans un shell je lance 'xclock'. dans un autre shell (mais pas sous-shell du premier) je veux faire un wait $(PID_XCLOCK). marche pas! comment faire?
Error: File /usr/src/linux-2.6.24/arch/x86_64/boot - No such file or directory
???
J'ai l'impression qu'il s'emmêle les pinceaux... il n'y a plus que je sache, de répertoire arch/x86_64 avec le 2.6.24. Alors pourquoi cherche t'il quelque chose là-bas?
[^] # Re: ben comme tu le fais deja ?
Posté par minitchoup . En réponse au message peut-on utiliser un filtre d'affichage dans aptitude ?. Évalué à 2. Dernière modification le 09 janvier 2020 à 13:38.
Oui… c'est pas clair.
La fonction de recherche opère de la même manière que dans un traitement de texte. Elle localise dans l'ensemble visualisé, les éléments qui répondent au critère et te permet de naviguer d'un élément à l'autre. Pour autant, tous les éléments sont visibles.
Ce que je voudrais, c'est ne voir que les éléments répondants à mes critères d'affichage.
[^] # Re: Faut traduire
Posté par minitchoup . En réponse au message Plasma sous Wayland, et Spectacle. Évalué à 0.
C'est très clair. Merci pour ces précisions.
Peut-on vouloir le beurre et l'argent du beurre ?
Il faudrait pouvoir coupler ces mécaniques de sécurité Wayland avec les systèmes déjà existants : SElinux, AppArmor, … de sorte notamment, qu'il ne faille pas redéclarer à chaque fois les mêmes autorisations.
Mais c'est une autre histoire.
[^] # Re: Faut traduire
Posté par minitchoup . En réponse au message Plasma sous Wayland, et Spectacle. Évalué à 3.
Merci pour ce lien, très instructif.
D'abord il me confirme la vision que j'ai de Wayland et du fonctionnement attendu d'une application de capture d'écran :
Mais il va de soi que l'article qui a été rédigé fin 2016,
n'est pas d'actualité: j'ai fait l'essai hier de lancer Plama/Wayland (Debian Buster) et de faire une capture de l'intégralité de l'écran.Aucune confirmation ne m'a été demandée !!!En fait si, je me suis merdé : une action utilisateur est bien réclamée; une vignette est affichée pour demander à l'utilisateur de confirmer ou d'annuler l'opération ! Super ! Mais tout n'est pas clair pour autant :
Scénario "a" :
1) Spectacle : ok, je veux faire la capture de l'écran, et l'utilisateur m'a donné son accord.
2) Wayland : Ah. Bon ben, s'il est ok, je suis ok.
Scénario "b" :
1) Malware : ok, je veux faire la capture de l'écran, et l'utilisateur m'a donné son accord (mensonge).
2) Wayland : Ah. Bon ben, s'il est ok, je suis ok.
Alors évidemment, je pense qu'il manque des étapes et des composants, et que tout cela n'est pas aussi simple. J'entrevois même une complexité affolante !
[^] # Re: Oui mais quand est-il des processus lancés au démarrage (systemd) ?
Posté par minitchoup . En réponse au message Comment interdire par défaut, l'accès aux réseaux pour toutes les applications ?. Évalué à 3.
Autre méthode (peut-être) : écrire un "hook" qui se charge à la création d'un processus de le positionner dans le NetNS "NO-NET".
Hooking sys_execve on Linux kernel 4.6 or higher
[^] # Oui mais quand est-il des processus lancés au démarrage (systemd) ?
Posté par minitchoup . En réponse au message Comment interdire par défaut, l'accès aux réseaux pour toutes les applications ?. Évalué à 3.
Effectivement, tant que le service NetNSAdm (celui qu'il nous faut écrire) n'a pas démarré, il faut qu'aucune application n'est droit d'accès au réseau !
Dans le man de "ip netns" il est dit :
Ok, donc il suffirait d'imposer un nom de domaine réseau (sans accès) au processus init :
Run a systemd unit in a specified network namespace
La suite au prochain épisode…
# Des choses existent déjà !
Posté par minitchoup . En réponse au message Comment interdire par défaut, l'accès aux réseaux pour toutes les applications ?. Évalué à 2.
Merci à tous pour vos liens : firejail, douane et OpenSnitch.
Il y a sans doute de bonnes choses à (ap)prendre.
J’essaierai de vous faire un retour.
# Idée de daemon
Posté par minitchoup . En réponse au message Comment interdire par défaut, l'accès aux réseaux pour toutes les applications ?. Évalué à 3. Dernière modification le 04 octobre 2019 à 18:44.
Voici ce à quoi j'ai pensé. Proposez-moi mieux, plus simple, de déjà existant… Partagez vos idées !
Au lancement du service (qu'il nous faut écrire ;) :
- changer netns de tous les processus ayant un exe dans leur proc pour NONET (aucune interface déclarée)
- création de tous les netns nécessaires pour la configuration
- appliquer la configuration avec un processus de surveillance :
Fichier de configuration :
Exemple :
Le processus de surveillance réalise les opérations suivantes (ttes les n secondes) :
Si parmi la liste des processus enregistrés certains n'existent plus, alors ils sont retirés de la liste.
[^] # Re: MAC
Posté par minitchoup . En réponse au message Comment interdire par défaut, l'accès aux réseaux pour toutes les applications ?. Évalué à 2.
Je ne connais pas SELinux. Un peu plus AppArmor… Dans mon exemple je parle d'Eclipse, application pour laquelle je voulais interdire tout accès au net. J'ai dû écrire un profil AppArmor pour cela… Pour moi, c'est vraiment trop compliqué. Alors que le besoin est simple !
Maintenant, pour le cas d'Eclipse, je ne passe plus par AA. Mais bien par la commande "ip netns exec". Je pense que la solution passe par cette commande. Je creuse…
https://manpages.debian.org/unstable/iproute2/ip-netns.8.en.html
[^] # Re: si tu veux couper l'accès réseaux pour TOUTES les applications
Posté par minitchoup . En réponse au message Comment interdire par défaut, l'accès aux réseaux pour toutes les applications ?. Évalué à -1. Dernière modification le 04 octobre 2019 à 14:31.
Non.
[^] # Re: nope
Posté par minitchoup . En réponse au message X11 et le vol par capture d'images. Évalué à 3.
Tu parles des accès disques. Les systèmes de fichiers offrent des protections pour les sécuriser.
Pourquoi rien n'existe avec X ?
J'ai trouvé aussi ça, qui va dans le sens de tout ce que vous dites : wayland-vs-xorg
Un passage intéressant :
La démonstration qui est faite dans la suite de l'article, avec xinput et sudo (mais ça marche évidemment avec tout) est saisissante, vertigineuse. xev fait aussi le job.
Et après on nous bassine sur l'utilité de choisir de bons mots de passe, sur la performance de tel ou tel technologie de cryptage, sur l'isolation par conteneur… mais que valent tout ça quand le système est pourri à la base ?
Il reste plusieurs solutions, que vous avez suggérées, en agissant, non pas sur la capture d'informations périphériques E/S, mais en agissant sur la capacité que peut avoir une application à communiquer avec le monde extérieur "malveillant" partant du principe, maintenant, qu'elle a accès à tout, en tout cas à l'essentiel :
- se déconnecter du monde
- isoler du réseau toutes les applications qui ne devraient pas en avoir usage; là SELinux ou AppArmor restent encore efficaces.
- passer en mode console, en changeant d'utilisateur (=> avec des droits restreints), pour surfer, télécharger, jouer,… :(
Bref, c'est mission impossible !
Heureusement, on peut quand même compter sur l'accès au code source, sur les très mauvaises retombées médiatiques qui frapperaient tous concepteurs d'applications malicieux s’adonnant à l'espionnage mais découverts… ;)
[^] # Re: nope
Posté par minitchoup . En réponse au message X11 et le vol par capture d'images. Évalué à 2.
MS-Windows n'est pas mon problème. Je laisse le SI de ma boîte se débrouiller avec ça. Chez moi, c'est Linux le problème ;)
Super ! Bon je vais bien me rencarder sur le sujet. Même si cela semble poser des problèmes au fonctionnement de Steam… Tiens donc…
Anecdote au passage : je fais tourner Steam dans un conteneur Lxc. Dans ce conteneur j'avais également Firefox installé. Saviez-vous que celui-ci démarre en mode "Remote" par défaut ? Cela donne accès à tout ce qui est vu de processus Firefox parent, celui là même qui est lancé depuis la machine hôte (en dehors du conteneur). Ben voyons ! C'est open bar !
Merci à tous pour les infos.
[^] # Re: nope
Posté par minitchoup . En réponse au message X11 et le vol par capture d'images. Évalué à 1.
Tout cela semble bien exact. Et inquiétant. Le "système" semble tellement contenir de failles que je me demande si on n'est pas dans l'erreur. Ce doit être plus compliqué que ça… Car si faille il y a, alors elle est sans doute exploitées.
[^] # Re: nope
Posté par minitchoup . En réponse au message X11 et le vol par capture d'images. Évalué à 5.
Donc si je comprends bien, n'importe quel logiciel GUI en cours d'exécution, a la possibilité de faire la capture de tout l'écran sans qu'il en ait à répondre à personne ?
Alors avec Wayland, sais-tu, savez-vous, si des mécanismes d'autorisations ont été prévu ? Quels en sont les principes ?
Par exemple, est-il possible d'indiquer que les ressources graphiques (fenêtres) de tel processus ou groupe de processus sont accessibles ou non pour d'autres processus du système ?
Par exemple, me serait-il possible de configurer le système, pour que par défaut, tout processus ne puisse utiliser uniquement SES ressources visuelles ?
Quand je lance mon trousseau KeepassX je serais vachement plus serein si j'avais la certitude qu'au moment où je visualise un mot de passe généré, en clair, celui-ci n'ait pas été capturé par je ne sais quelle autre application malveillante.
C'est moi, ou cette absence de sécurité sur les contenus visuels semble préoccuper personne ? Dit autrement, je m'inquiète pour rien ?
PS : je vais regarder cette histoire de DRM…
Merci à tous pour vos réponses.
[^] # Re: Non
Posté par minitchoup . En réponse au message X11 et le vol par capture d'images. Évalué à 1.
Quand je parle d'interdire l'accès à l'affichage d'une application, je me suis mal exprimé, je voulais dire empêcher toute autre application d'accéder au contenu des fenêtres de cette application.
[^] # Re: C'est pas ton executable
Posté par minitchoup . En réponse au message AppArmor : de la sureté de lancer un audit d'application en super-utilisateur (root). Évalué à 2.
Oui. C'est exact ! Merci ! Je suis allé trop vite, et j'avais finalement rien compris!
Le tuto en question est ici.
Le cas qui me pose problème (l'application à auditer est lancer en root) c'est celui là : «processus à durée limitée».
Mais pour moi qui voulait faire l'audit d'Eclipse, j'aurais dû d'avantage m'intéresser à celui-ci : «processus de type daemon» qui ne pose aucun problème de sécurité puisque jamais l'application à auditer ne doit être lancée en super-utilisateur.
En effet, pour réaliser l'audit de l'application Eclipse :
[^] # Re: Gni?
Posté par minitchoup . En réponse au message AppArmor : de la sureté de lancer un audit d'application en super-utilisateur (root). Évalué à 2.
Le problème n'est pas celui des outils AppArmor me semble t-il, mais celui de devoir lancer l'application à auditer en tant que root.
Pour réaliser l'audit d'Eclipse, il m'est demander de faire :
Je conçois que aa-autodep ait besoin des droits SU pour faire l'audit, mais qu'eclipse soit exécuté en root me gêne beaucoup…
# Les jeux sur PC/Linux... PLus que ceux GPL.
Posté par minitchoup . En réponse au journal Quand on veut, on peut.. Évalué à 1.
- je n'ai plus de double boot sur ma machine mais uniquement du Linux.
- je ne file plus un radis à Micro-mes-c...es. Bon je ne suis pas certain que dans l'esprit Sony soit meilleur mais bon... c'est pas pareil...
- pas de soft proprio sur ma machine!
- et j'anticipe une remarque : au niveau prix c'est similaire. Le prix des jeux, si l'on n'est pas pressé, tombe au environ de 30 euros au bout d'un an après leur sortie. Le prix de la console est équivalent à celui que m'aurait coutait l'upgrade matérielle pour avoir l'équivalent sur PC (là mon PC je peux espérer le conserver en l'état... très longtemps).
- il n'empêche : j'adore Battle of Wesnoth.
[^] # Re: la scrutation c'est pas top
Posté par minitchoup . En réponse au message attendre la fin d'un processus créé depuis un autre shell. Évalué à 1.
Il est possible, je n'ai pas fait mais j'en suis aussi convaincu, d'écrire (même en bash) un programme de démarrage et de surveillance qui :
- à son lancement, démarre l'application indiquée
- envoie dans le pipe désigné un "signal" dès que l'application se termine
avantage :
- l'application est un processus enfant du shell => le programme peut utiliser un wait
- le programme "client" qui veut être informé peut se mettre en attente d'un evt sur le pipe sans consommer de CPU (lecture synchrone)/
inconvénient :
- pour l'instant, seul un/le client peut être informé de la terminaison de l'application
- c'est dingue (je trouve) d'en arriver là. Le besoin me parait simple et légitime. Mais bon je ne prétendrait pas avoir exploré toutes les solutions...
# la scrutation c'est pas top
Posté par minitchoup . En réponse au message attendre la fin d'un processus créé depuis un autre shell. Évalué à 2.
les problèmes de la scrutation périodique :
1/ si la vérification a lieu toutes les secondes, il peut dans le pire cas se passer une seconde entre la terminaison du processus et le moment où elle est détectée
2/ le process de surveillance consomme du CPU inutilement (d'autant plus que la période de scrutation est courte)
Pour cela je trouve la solution suggérée par 'rb14' plus intéressante (le coup du strace). J'attends une solution qui mette en oeuvre une spécificité du noyau (sorte de wait). peut être que je jetterai un œil sur le code du strace.
[^] # Re: Re
Posté par minitchoup . En réponse au message attendre la fin d'un processus créé depuis un autre shell. Évalué à 2.
dans un shell je lance 'xclock'. dans un autre shell (mais pas sous-shell du premier) je veux faire un wait $(PID_XCLOCK). marche pas! comment faire?
# [Solution]
Posté par minitchoup . En réponse au message Pb compilation linux-2.6.24 sur x86_64. Évalué à 1.
Ainsi,
# make CC="gcc" LD="ld" AS="as" mrproper
# make CC="gcc" LD="ld" AS="as" oldconfig
# make CC="gcc" LD="ld" AS="as"
fonctionne tous les 3 sans problème. Pourquoi? C'est une autre question...
[^] # Re: make oldconfig
Posté par minitchoup . En réponse au message Pb compilation linux-2.6.24 sur x86_64. Évalué à 0.
merci.
(moi je n'ai pas ce répertoire pour la version 2.6.24 du noyau)
[^] # Re: make oldconfig
Posté par minitchoup . En réponse au message Pb compilation linux-2.6.24 sur x86_64. Évalué à 2.
merci.
(moi je n'ai pas ce répertoire pour la version 2.6.24 du noyau)
[^] # Re: hmmm
Posté par minitchoup . En réponse au message Pb compilation linux-2.6.24 sur x86_64. Évalué à 1.
je peux configurer le noyau, mais au moment de faire "make", j'ai droit au message d'erreur.
Merci quand même.
[^] # Re: mrproper
Posté par minitchoup . En réponse au message Pb compilation linux-2.6.24 sur x86_64. Évalué à 1.
# make mrproper
Error: File /usr/src/linux-2.6.24/arch/x86_64/boot - No such file or directory
???
J'ai l'impression qu'il s'emmêle les pinceaux... il n'y a plus que je sache, de répertoire arch/x86_64 avec le 2.6.24. Alors pourquoi cherche t'il quelque chose là-bas?
Merci quand même!