Moyen de ne pas afficher les arguments d'un process
24 réponses
Kevin Denis
Bonjour,
je dois utiliser temporairement un soft sous linux.
Ce soft prend toutes ses options en ligne de commande. La conséquence, c'est
que toute personne qui fait un ps axww peut lire l'ensemble des options
utilisées.
Exemple: $ ./mon_soft -X -login=toto -password=secret -options
Depuis un autre accès: ps axww et à moi le password!
Ca m'ennuie un peu de voir trainer ce genre de choses dans un ps ax.
Existe t'il un moyen simple (avant que je ne change de soft) de lancer
un programme sous linux avec des options sans qu'on les affiche avec un
ps ax? J'ai naïvement tenté de faire un alias ou un wrapper C contenant
un appel system("mon_soft"), mais ça ne fonctionne pas.
Existe t'il un moyen simple (avant que je ne change de soft) de lancer un programme sous linux avec des options sans qu'on les affiche avec un ps ax?
Non. Le programme lui-même peut changer cet affichage, mais à moins de le ptracer pour le forcer à faire ça, il n'y a pas moyen de le faire de l'extérieur.
Si ce soft ne prévoit pas de moyen pour recevoir le mot de passe par une variable d'environnement (les Unix décent ne permettent pas de lire l'environnement des processus appartenant à autrui) ou un file descriptor, il est bon à jeter.
Kevin Denis , dans le message
<slrnko536i.m29.kevin@slackwall.local.tux>, a écrit :
Existe t'il un moyen simple (avant que je ne change de soft) de lancer
un programme sous linux avec des options sans qu'on les affiche avec un
ps ax?
Non. Le programme lui-même peut changer cet affichage, mais à moins de le
ptracer pour le forcer à faire ça, il n'y a pas moyen de le faire de
l'extérieur.
Si ce soft ne prévoit pas de moyen pour recevoir le mot de passe par une
variable d'environnement (les Unix décent ne permettent pas de lire
l'environnement des processus appartenant à autrui) ou un file descriptor,
il est bon à jeter.
Existe t'il un moyen simple (avant que je ne change de soft) de lancer un programme sous linux avec des options sans qu'on les affiche avec un ps ax?
Non. Le programme lui-même peut changer cet affichage, mais à moins de le ptracer pour le forcer à faire ça, il n'y a pas moyen de le faire de l'extérieur.
Si ce soft ne prévoit pas de moyen pour recevoir le mot de passe par une variable d'environnement (les Unix décent ne permettent pas de lire l'environnement des processus appartenant à autrui) ou un file descriptor, il est bon à jeter.
Vieux, tu peux le dire. Complètement périmé, même.
#include <stdio.h>
main(argc, argv)
Déclaration de type de retour manquante.
char **argv;
Déclaration de type pré-ANSI. Ça fait un quart de siècle que c'est obsolète.
{ int i; char *p;
for (i = 1; i < argc; i++) { p = argv[i]; while (*p) *p++ = 'X'; }
getchar(); }
return manquant.
Verifie que les paramètres ont disparu du fichier /proc/(PID)/cmdline, qu'utilise ps(1)..
Ça lui fera une belle jambe, que les paramètres aient disparu d'un programme qui ne fait rien.
Bruno Ducrot
On 2013-05-02, Kevin Denis wrote:
Bonjour,
je dois utiliser temporairement un soft sous linux. Ce soft prend toutes ses options en ligne de commande. La conséquence, c'est que toute personne qui fait un ps axww peut lire l'ensemble des options utilisées.
Exemple: $ ./mon_soft -X -login=toto -password=secret -options Depuis un autre accès: ps axww et à moi le password!
Ca m'ennuie un peu de voir trainer ce genre de choses dans un ps ax. Existe t'il un moyen simple (avant que je ne change de soft) de lancer un programme sous linux avec des options sans qu'on les affiche avec un ps ax? J'ai naïvement tenté de faire un alias ou un wrapper C contenant un appel system("mon_soft"), mais ça ne fonctionne pas.
Je ne sais répondre à ta question. Par contre, tu peux utiliser l'option 'hidepid' lors du montage de ton /proc, ce qui permet de cacher les process dont l'uid n'est pas celui de l'appelant.
Pour tester :
mount -o remount,hidepid=1 proc /proc ps axuww (en tant qu'utilisateur normal) ls /proc
(on voit malgré tout l'arboresecence de tous les process).
mount -o remount,hidepid=2 proc /proc ps axuww (en tant qu'utilisateur normal) ls /proc (les répertoires ne sont plus visibles, par exemple ls /proc/1 renvoie une erreur).
Enfin mount -o remount,hidepid=0 proc /proc pour revenir au mode normal.
Il t'appartiendra alors de modifier /etc/fstab en conséquence, par exemple avec : proc /proc procfs hidepid=2,gidP0 0 0
Note final, l'option gidP0 permet à un process, dont l'egid est 500, de pouvoir malgré tout accéder à l'ensemble des process, ce qui peut s'avérer utile pour certains process dont le rôle est de monitorer le système.
A plus,
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2013-05-02, Kevin Denis wrote:
Bonjour,
je dois utiliser temporairement un soft sous linux.
Ce soft prend toutes ses options en ligne de commande. La conséquence, c'est
que toute personne qui fait un ps axww peut lire l'ensemble des options
utilisées.
Exemple: $ ./mon_soft -X -login=toto -password=secret -options
Depuis un autre accès: ps axww et à moi le password!
Ca m'ennuie un peu de voir trainer ce genre de choses dans un ps ax.
Existe t'il un moyen simple (avant que je ne change de soft) de lancer
un programme sous linux avec des options sans qu'on les affiche avec un
ps ax? J'ai naïvement tenté de faire un alias ou un wrapper C contenant
un appel system("mon_soft"), mais ça ne fonctionne pas.
Je ne sais répondre à ta question. Par contre, tu peux utiliser
l'option 'hidepid' lors du montage de ton /proc, ce qui permet
de cacher les process dont l'uid n'est pas celui de l'appelant.
Pour tester :
mount -o remount,hidepid=1 proc /proc
ps axuww (en tant qu'utilisateur normal)
ls /proc
(on voit malgré tout l'arboresecence de tous les process).
mount -o remount,hidepid=2 proc /proc
ps axuww (en tant qu'utilisateur normal)
ls /proc
(les répertoires ne sont plus visibles, par exemple ls /proc/1
renvoie une erreur).
Enfin
mount -o remount,hidepid=0 proc /proc
pour revenir au mode normal.
Il t'appartiendra alors de modifier /etc/fstab en conséquence, par exemple
avec :
proc /proc procfs hidepid=2,gidP0 0 0
Note final, l'option gidP0 permet à un process, dont l'egid est 500, de
pouvoir malgré tout accéder à l'ensemble des process, ce qui peut
s'avérer utile pour certains process dont le rôle est de monitorer
le système.
je dois utiliser temporairement un soft sous linux. Ce soft prend toutes ses options en ligne de commande. La conséquence, c'est que toute personne qui fait un ps axww peut lire l'ensemble des options utilisées.
Exemple: $ ./mon_soft -X -login=toto -password=secret -options Depuis un autre accès: ps axww et à moi le password!
Ca m'ennuie un peu de voir trainer ce genre de choses dans un ps ax. Existe t'il un moyen simple (avant que je ne change de soft) de lancer un programme sous linux avec des options sans qu'on les affiche avec un ps ax? J'ai naïvement tenté de faire un alias ou un wrapper C contenant un appel system("mon_soft"), mais ça ne fonctionne pas.
Je ne sais répondre à ta question. Par contre, tu peux utiliser l'option 'hidepid' lors du montage de ton /proc, ce qui permet de cacher les process dont l'uid n'est pas celui de l'appelant.
Pour tester :
mount -o remount,hidepid=1 proc /proc ps axuww (en tant qu'utilisateur normal) ls /proc
(on voit malgré tout l'arboresecence de tous les process).
mount -o remount,hidepid=2 proc /proc ps axuww (en tant qu'utilisateur normal) ls /proc (les répertoires ne sont plus visibles, par exemple ls /proc/1 renvoie une erreur).
Enfin mount -o remount,hidepid=0 proc /proc pour revenir au mode normal.
Il t'appartiendra alors de modifier /etc/fstab en conséquence, par exemple avec : proc /proc procfs hidepid=2,gidP0 0 0
Note final, l'option gidP0 permet à un process, dont l'egid est 500, de pouvoir malgré tout accéder à l'ensemble des process, ce qui peut s'avérer utile pour certains process dont le rôle est de monitorer le système.
A plus,
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
JKB
Le Thu, 2 May 2013 20:23:43 +0200, xtof écrivait :
Le 02 May 2013 13:10:42 GMT, Kevin Denis a écrit :
Bonjour,
je dois utiliser temporairement un soft sous linux. Ce soft prend toutes ses options en ligne de commande. La conséquence, c'est que toute personne qui fait un ps axww peut lire l'ensemble des options utilisées.
(...)
Pour masquer les paramètres d'une commande, sous Linux, on peut utiliser ce vieux truc:
#include <stdio.h>
main(argc, argv) char **argv; { int i; char *p;
for (i = 1; i < argc; i++) { p = argv[i]; while (*p) *p++ = 'X'; }
getchar(); }
Verifie que les paramètres ont disparu du fichier /proc/(PID)/cmdline, qu'utilise ps(1)..
Personnellement, je n'ai jamais essayé, mais j'utiliserais plutôt un NULL. J'ai pour idée que ./prog "" pourrait joyeusement segfaulter...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 2 May 2013 20:23:43 +0200,
xtof <xtof.pernod@free.fr> écrivait :
Le 02 May 2013 13:10:42 GMT,
Kevin Denis <kevin@nowhere.invalid> a écrit :
Bonjour,
je dois utiliser temporairement un soft sous linux.
Ce soft prend toutes ses options en ligne de commande. La
conséquence, c'est que toute personne qui fait un ps axww peut lire
l'ensemble des options utilisées.
(...)
Pour masquer les paramètres d'une commande, sous Linux, on peut
utiliser ce vieux truc:
#include <stdio.h>
main(argc, argv) char **argv;
{
int i;
char *p;
for (i = 1; i < argc; i++) {
p = argv[i];
while (*p)
*p++ = 'X';
}
getchar();
}
Verifie que les paramètres ont disparu du fichier /proc/(PID)/cmdline,
qu'utilise ps(1)..
Personnellement, je n'ai jamais essayé, mais j'utiliserais plutôt un
NULL. J'ai pour idée que ./prog "" pourrait joyeusement
segfaulter...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 2 May 2013 20:23:43 +0200, xtof écrivait :
Le 02 May 2013 13:10:42 GMT, Kevin Denis a écrit :
Bonjour,
je dois utiliser temporairement un soft sous linux. Ce soft prend toutes ses options en ligne de commande. La conséquence, c'est que toute personne qui fait un ps axww peut lire l'ensemble des options utilisées.
(...)
Pour masquer les paramètres d'une commande, sous Linux, on peut utiliser ce vieux truc:
#include <stdio.h>
main(argc, argv) char **argv; { int i; char *p;
for (i = 1; i < argc; i++) { p = argv[i]; while (*p) *p++ = 'X'; }
getchar(); }
Verifie que les paramètres ont disparu du fichier /proc/(PID)/cmdline, qu'utilise ps(1)..
Personnellement, je n'ai jamais essayé, mais j'utiliserais plutôt un NULL. J'ai pour idée que ./prog "" pourrait joyeusement segfaulter...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Il ne fait pas rien. Il masque les paramètres qu'il a reçu.
Et c'est tout. Il n'en fait strictement rien.
JKB
Le Fri, 3 May 2013 13:21:52 +0200, xtof pernod écrivait :
Le Fri, 3 May 2013 09:19:29 +0000 (UTC), JKB a écrit :
Le Thu, 2 May 2013 20:23:43 +0200, xtof écrivait : > Le 02 May 2013 13:10:42 GMT, > Kevin Denis a écrit : > >> (...) J'ai pour idée que ./prog "" pourrait joyeusement segfaulter...
JKB
Nope, ça passe. La boucle est "while (*p)", et s'arrête donc au 1er octet nul..
J'ai lu le truc en diagonale (et tu l'as effacé de ma réponse). De mémoire, à un moment, tu colles 'X' dans l'argument courant. Si l'argument courant était "", il risque de se passer des choses parce que tu remplaces un caractère de fin de chaîne par un autre caractère non nul (où se trouve alors la fin de la chaîne ?). Par ailleurs, je ne suis pas sûr que cette mémoire soit accessible en écriture de façon portable (si tu fais ça sur un VMS des familles, tu te prends un coup de pied aux fesses bien mérité).
Enfin, c'était le pinaillage de trolldi.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Fri, 3 May 2013 13:21:52 +0200,
xtof pernod <xtof.pernod@free.fr> écrivait :
Le Fri, 3 May 2013 09:19:29 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> a écrit :
Le Thu, 2 May 2013 20:23:43 +0200,
xtof <xtof.pernod@free.fr> écrivait :
> Le 02 May 2013 13:10:42 GMT,
> Kevin Denis <kevin@nowhere.invalid> a écrit :
>
>> (...)
J'ai pour idée que ./prog "" pourrait joyeusement
segfaulter...
JKB
Nope, ça passe. La boucle est "while (*p)", et s'arrête donc au 1er
octet nul..
J'ai lu le truc en diagonale (et tu l'as effacé de ma réponse). De
mémoire, à un moment, tu colles 'X' dans l'argument courant. Si
l'argument courant était "", il risque de se passer des choses parce
que tu remplaces un caractère de fin de chaîne par un autre
caractère non nul (où se trouve alors la fin de la chaîne ?). Par
ailleurs, je ne suis pas sûr que cette mémoire soit accessible en
écriture de façon portable (si tu fais ça sur un VMS des familles, tu
te prends un coup de pied aux fesses bien mérité).
Enfin, c'était le pinaillage de trolldi.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Fri, 3 May 2013 13:21:52 +0200, xtof pernod écrivait :
Le Fri, 3 May 2013 09:19:29 +0000 (UTC), JKB a écrit :
Le Thu, 2 May 2013 20:23:43 +0200, xtof écrivait : > Le 02 May 2013 13:10:42 GMT, > Kevin Denis a écrit : > >> (...) J'ai pour idée que ./prog "" pourrait joyeusement segfaulter...
JKB
Nope, ça passe. La boucle est "while (*p)", et s'arrête donc au 1er octet nul..
J'ai lu le truc en diagonale (et tu l'as effacé de ma réponse). De mémoire, à un moment, tu colles 'X' dans l'argument courant. Si l'argument courant était "", il risque de se passer des choses parce que tu remplaces un caractère de fin de chaîne par un autre caractère non nul (où se trouve alors la fin de la chaîne ?). Par ailleurs, je ne suis pas sûr que cette mémoire soit accessible en écriture de façon portable (si tu fais ça sur un VMS des familles, tu te prends un coup de pied aux fesses bien mérité).
Enfin, c'était le pinaillage de trolldi.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
