apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un
exécutable (par ex en c)
est ce qu'il existe des exécutables prévus à cet effet, pour lancer une
autre commande et pas n'importe lesquelles ?
ou bien il faut que je me paye cette programmation ?
--
j'agis contre l'assistanat, je travaille dans une SCOP !
In article <20071203173328$, Vincent Lefevre <vincent+ wrote:
C'est utile quand plusieurs utilisateurs partagent la même machine.
J'ai utilisé ça quand on était deux à travailler à tour de rôle sur un projet. On était les deux membres d'un groupe lié au projet, et le répertoire en question avait un ACL pour que les fichiers crées par l'un ou l'autre puisse être modifié par les membres de ce groupe. Or dans certains cas, l'ACL n'était pas respecté et le fichier n'était accessible qu'en lecture pour le groupe. Un script "suid" exécuté au login permettait à chaque utilisateur de corriger les permissions sur les fichiers appartenant au collègue, et donc de modifier lesdits fichiers.
Patrick -- Patrick Stadelmann
In article <20071203173328$45dc@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> wrote:
C'est utile quand plusieurs utilisateurs partagent la même machine.
J'ai utilisé ça quand on était deux à travailler à tour de rôle sur un
projet. On était les deux membres d'un groupe lié au projet, et le
répertoire en question avait un ACL pour que les fichiers crées par l'un
ou l'autre puisse être modifié par les membres de ce groupe. Or dans
certains cas, l'ACL n'était pas respecté et le fichier n'était
accessible qu'en lecture pour le groupe. Un script "suid" exécuté au
login permettait à chaque utilisateur de corriger les permissions sur
les fichiers appartenant au collègue, et donc de modifier lesdits
fichiers.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <20071203173328$, Vincent Lefevre <vincent+ wrote:
C'est utile quand plusieurs utilisateurs partagent la même machine.
J'ai utilisé ça quand on était deux à travailler à tour de rôle sur un projet. On était les deux membres d'un groupe lié au projet, et le répertoire en question avait un ACL pour que les fichiers crées par l'un ou l'autre puisse être modifié par les membres de ce groupe. Or dans certains cas, l'ACL n'était pas respecté et le fichier n'était accessible qu'en lecture pour le groupe. Un script "suid" exécuté au login permettait à chaque utilisateur de corriger les permissions sur les fichiers appartenant au collègue, et donc de modifier lesdits fichiers.
Patrick -- Patrick Stadelmann
blanc
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Tu est sur quel système ?
Tiger 10.4.11 mais faut peut-être installer le pack developpeur
Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne me renseignent à ce sujet.
Alors Google est ton ami : <http://www.google.fr/search?hl=fr&q=man+2+intro&btnG=Recherche+Google&m eta=>
Le premier lien est le bon !... et en cherchant un peu, tu dois pouvoir troubver en français :-)
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Tu est sur quel système ?
Tiger 10.4.11 mais faut peut-être installer le pack developpeur
Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne
me renseignent à ce sujet.
Alors Google est ton ami :
<http://www.google.fr/search?hl=fr&q=man+2+intro&btnG=Recherche+Google&m
eta=>
Le premier lien est le bon !...
et en cherchant un peu, tu dois pouvoir troubver en français :-)
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Alors Google est ton ami : <http://www.google.fr/search?hl=fr&q=man+2+intro&btnG=Recherche+Google&m eta=>
Le premier lien est le bon !...
Ok, merci. C'est le "man 2 intro" de OpenBSD (et de Apple, mais ce man est absent sur mon mac) qui donne les info dont tu parlais. Je vais enfin pouvoir les lire :)
Par contre les man pages linux n'ont pas cette info. http://swoolley.org/man.cgi/2/intro
Bref, désolé. J'aurais pu trouver tout seul mais j'ai cette habitude de lire les pages de man via le terminal, pas via le web.
et en cherchant un peu, tu dois pouvoir troubver en français :-)
Les man pages linux sont traduites, mais quid des pages Apple ou BSD ? (ceci dit j'arrive à lire des man en anglais, quand je les trouve :)
Pour résumer donc (des fois que je ne sois pas le seul à nager) et si j'ai tout compris :
toto tapes "ps" dans son terminal.
Le "Real User ID" c'est toto.
Le " Effective User Id" est root puisque le "set-user-ID" est mis et que root est le possesseur du fichier /bin/ps
Le "Saved Set User ID", si la commande "ps" était sensée créer des fichiers, serait le possesseur de ces fichiers et serait, d'après le man, le "effective user".
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
JiPaul <blanc@empty.org> wrote:
Alors Google est ton ami :
<http://www.google.fr/search?hl=fr&q=man+2+intro&btnG=Recherche+Google&m
eta=>
Le premier lien est le bon !...
Ok, merci.
C'est le "man 2 intro" de OpenBSD (et de Apple, mais ce man est absent
sur mon mac) qui donne les info dont tu parlais.
Je vais enfin pouvoir les lire :)
Par contre les man pages linux n'ont pas cette info.
http://swoolley.org/man.cgi/2/intro
Bref, désolé. J'aurais pu trouver tout seul mais j'ai cette habitude de
lire les pages de man via le terminal, pas via le web.
et en cherchant un peu, tu dois pouvoir troubver en français :-)
Les man pages linux sont traduites, mais quid des pages Apple ou BSD ?
(ceci dit j'arrive à lire des man en anglais, quand je les trouve :)
Pour résumer donc (des fois que je ne sois pas le seul à nager) et si
j'ai tout compris :
toto tapes "ps" dans son terminal.
Le "Real User ID" c'est toto.
Le " Effective User Id" est root puisque le "set-user-ID" est mis et que
root est le possesseur du fichier /bin/ps
Le "Saved Set User ID", si la commande "ps" était sensée créer des
fichiers, serait le possesseur de ces fichiers et serait, d'après le
man, le "effective user".
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Alors Google est ton ami : <http://www.google.fr/search?hl=fr&q=man+2+intro&btnG=Recherche+Google&m eta=>
Le premier lien est le bon !...
Ok, merci. C'est le "man 2 intro" de OpenBSD (et de Apple, mais ce man est absent sur mon mac) qui donne les info dont tu parlais. Je vais enfin pouvoir les lire :)
Par contre les man pages linux n'ont pas cette info. http://swoolley.org/man.cgi/2/intro
Bref, désolé. J'aurais pu trouver tout seul mais j'ai cette habitude de lire les pages de man via le terminal, pas via le web.
et en cherchant un peu, tu dois pouvoir troubver en français :-)
Les man pages linux sont traduites, mais quid des pages Apple ou BSD ? (ceci dit j'arrive à lire des man en anglais, quand je les trouve :)
Pour résumer donc (des fois que je ne sois pas le seul à nager) et si j'ai tout compris :
toto tapes "ps" dans son terminal.
Le "Real User ID" c'est toto.
Le " Effective User Id" est root puisque le "set-user-ID" est mis et que root est le possesseur du fichier /bin/ps
Le "Saved Set User ID", si la commande "ps" était sensée créer des fichiers, serait le possesseur de ces fichiers et serait, d'après le man, le "effective user".
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas-MICHEL'_remove_'
Vincent Lefevre <vincent+ wrote:
Dans l'article <1i8k26t.1dawlqw15f0k2dN%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Ceci dit immaginer faire ça sur un post dont on est pas admin, je vois mal ... Sur un serveur web éventuellement ?
C'est utile quand plusieurs utilisateurs partagent la même machine.
Avec plusieurs admin, sudo est un bon système : C'est le meilleur moyen amha pour gérer les mots de passe. Chacun le sien et le passwd root désactivé ou modifié aléatoirement. De cette façon quand quelqu'un part, il ne part pas avec le passwd root.
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je lançais mes calculs sur toutes les machines du labo. L'utilisateur principal de la machine pouvait ainsi tuer mes processus de calcul (et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller autrement sans avoir besoin de programme setuid (e.g. l'utilisateur crée un fichier dans le /tmp de la machine et mes programmes vérifient régulièrement).
sudo killall -hup tonscript ça ne te plais pas ?
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Dans l'article <1i8k26t.1dawlqw15f0k2dN%Nicolas-MICHEL'_remove_'@bluewin.ch>,
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Ceci dit immaginer faire ça sur un post dont on est pas admin, je vois
mal ... Sur un serveur web éventuellement ?
C'est utile quand plusieurs utilisateurs partagent la même machine.
Avec plusieurs admin, sudo est un bon système :
C'est le meilleur moyen amha pour gérer les mots de passe.
Chacun le sien et le passwd root désactivé ou modifié aléatoirement.
De cette façon quand quelqu'un part, il ne part pas avec le passwd root.
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je
lançais mes calculs sur toutes les machines du labo. L'utilisateur
principal de la machine pouvait ainsi tuer mes processus de calcul
(et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller
autrement sans avoir besoin de programme setuid (e.g. l'utilisateur
crée un fichier dans le /tmp de la machine et mes programmes vérifient
régulièrement).
sudo killall -hup tonscript
ça ne te plais pas ?
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Dans l'article <1i8k26t.1dawlqw15f0k2dN%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Ceci dit immaginer faire ça sur un post dont on est pas admin, je vois mal ... Sur un serveur web éventuellement ?
C'est utile quand plusieurs utilisateurs partagent la même machine.
Avec plusieurs admin, sudo est un bon système : C'est le meilleur moyen amha pour gérer les mots de passe. Chacun le sien et le passwd root désactivé ou modifié aléatoirement. De cette façon quand quelqu'un part, il ne part pas avec le passwd root.
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je lançais mes calculs sur toutes les machines du labo. L'utilisateur principal de la machine pouvait ainsi tuer mes processus de calcul (et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller autrement sans avoir besoin de programme setuid (e.g. l'utilisateur crée un fichier dans le /tmp de la machine et mes programmes vérifient régulièrement).
sudo killall -hup tonscript ça ne te plais pas ?
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Vincent Lefevre
Dans l'article <1i8l9nz.2ruftx1wr03wiN%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Vincent Lefevre <vincent+ wrote:
C'est utile quand plusieurs utilisateurs partagent la même machine.
Avec plusieurs admin, sudo est un bon système :
Les utilisateurs ne sont pas forcément admin. Typiquement dans un labo, il y a des machines gérées par des administrateurs, et les utilisateurs ne sont qu'utilisateurs (pas de droit de root).
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je lançais mes calculs sur toutes les machines du labo. L'utilisateur principal de la machine pouvait ainsi tuer mes processus de calcul (et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller autrement sans avoir besoin de programme setuid (e.g. l'utilisateur crée un fichier dans le /tmp de la machine et mes programmes vérifient régulièrement).
sudo killall -hup tonscript ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Dans l'article <1i8l9nz.2ruftx1wr03wiN%Nicolas-MICHEL'_remove_'@bluewin.ch>,
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Vincent Lefevre <vincent+news@vinc17.org> wrote:
C'est utile quand plusieurs utilisateurs partagent la même machine.
Avec plusieurs admin, sudo est un bon système :
Les utilisateurs ne sont pas forcément admin. Typiquement dans un labo,
il y a des machines gérées par des administrateurs, et les utilisateurs
ne sont qu'utilisateurs (pas de droit de root).
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je
lançais mes calculs sur toutes les machines du labo. L'utilisateur
principal de la machine pouvait ainsi tuer mes processus de calcul
(et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller
autrement sans avoir besoin de programme setuid (e.g. l'utilisateur
crée un fichier dans le /tmp de la machine et mes programmes vérifient
régulièrement).
sudo killall -hup tonscript
ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Dans l'article <1i8l9nz.2ruftx1wr03wiN%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Vincent Lefevre <vincent+ wrote:
C'est utile quand plusieurs utilisateurs partagent la même machine.
Avec plusieurs admin, sudo est un bon système :
Les utilisateurs ne sont pas forcément admin. Typiquement dans un labo, il y a des machines gérées par des administrateurs, et les utilisateurs ne sont qu'utilisateurs (pas de droit de root).
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je lançais mes calculs sur toutes les machines du labo. L'utilisateur principal de la machine pouvait ainsi tuer mes processus de calcul (et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller autrement sans avoir besoin de programme setuid (e.g. l'utilisateur crée un fichier dans le /tmp de la machine et mes programmes vérifient régulièrement).
sudo killall -hup tonscript ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Les utilisateurs ne sont pas forcément admin. Typiquement dans un labo, il y a des machines gérées par des administrateurs, et les utilisateurs ne sont qu'utilisateurs (pas de droit de root).
Oui, désolé, je ne sais pas pourquoi j'avais cru que tu parlais de plusieurs admin, pas de plusieurs utilisateurs. En te relisant je vois que c'est pas le cas.
Evidement, plus il y a d'admin et plus il y a de risques :)
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je lançais mes calculs sur toutes les machines du labo. L'utilisateur principal de la machine pouvait ainsi tuer mes processus de calcul (et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller autrement sans avoir besoin de programme setuid (e.g. l'utilisateur crée un fichier dans le /tmp de la machine et mes programmes vérifient régulièrement).
sudo killall -hup tonscript ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Dans le context d'utilisateurs non admin, on est bien d'accord.
Mais tu pourrais faire un script "killall -hup tonscript" et à l'autoriser dans le sudoer pour les utilisateurs donnés.
Enfin ça deviens une solution un poil compliquée pour remplacer une fonctionnalité simple :) -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Les utilisateurs ne sont pas forcément admin. Typiquement dans un labo,
il y a des machines gérées par des administrateurs, et les utilisateurs
ne sont qu'utilisateurs (pas de droit de root).
Oui, désolé, je ne sais pas pourquoi j'avais cru que tu parlais de
plusieurs admin, pas de plusieurs utilisateurs.
En te relisant je vois que c'est pas le cas.
Evidement, plus il y a d'admin et plus il y a de risques :)
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je
lançais mes calculs sur toutes les machines du labo. L'utilisateur
principal de la machine pouvait ainsi tuer mes processus de calcul
(et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller
autrement sans avoir besoin de programme setuid (e.g. l'utilisateur
crée un fichier dans le /tmp de la machine et mes programmes vérifient
régulièrement).
sudo killall -hup tonscript
ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Dans le context d'utilisateurs non admin, on est bien d'accord.
Mais tu pourrais faire un script "killall -hup tonscript"
et à l'autoriser dans le sudoer pour les utilisateurs donnés.
Enfin ça deviens une solution un poil compliquée pour remplacer une
fonctionnalité simple :)
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Les utilisateurs ne sont pas forcément admin. Typiquement dans un labo, il y a des machines gérées par des administrateurs, et les utilisateurs ne sont qu'utilisateurs (pas de droit de root).
Oui, désolé, je ne sais pas pourquoi j'avais cru que tu parlais de plusieurs admin, pas de plusieurs utilisateurs. En te relisant je vois que c'est pas le cas.
Evidement, plus il y a d'admin et plus il y a de risques :)
Par exemple, j'avais besoin de beaucoup de puissance de calcul et je lançais mes calculs sur toutes les machines du labo. L'utilisateur principal de la machine pouvait ainsi tuer mes processus de calcul (et seulement ceux-là). Bon, en fait, j'aurais pu me débrouiller autrement sans avoir besoin de programme setuid (e.g. l'utilisateur crée un fichier dans le /tmp de la machine et mes programmes vérifient régulièrement).
sudo killall -hup tonscript ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Dans le context d'utilisateurs non admin, on est bien d'accord.
Mais tu pourrais faire un script "killall -hup tonscript" et à l'autoriser dans le sudoer pour les utilisateurs donnés.
Enfin ça deviens une solution un poil compliquée pour remplacer une fonctionnalité simple :) -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Vincent Lefevre
Dans l'article <1i8quwb.hw23nx192mpf6N%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Dans le context d'utilisateurs non admin, on est bien d'accord.
Oui, c'était l'avantage du setuid: une solution adaptée *aussi* aux utilisateurs non admin.
Mais tu pourrais faire un script "killall -hup tonscript" et à l'autoriser dans le sudoer pour les utilisateurs donnés.
Oui, mais ça demande une intervention de l'admin. Cela pourrait être fait une fois pour toutes pour tous les utilisateurs avec un script, e.g. nommé "setuid", qui va exécuter le programme donné en argument s'il est dans un répertoire du style "~user/.setuid". Ainsi quand un utilisateur veut créer un programme avec la fonctionnalité du bit s, il peut le mettre dans son répertoire ~user/.setuid, et les autres utilisateurs l'exécutent par:
sudo -u <user> setuid <program> <args>
où <program> est un simple nom de fichier (sans /). Je ne pense pas qu'il y ait de problème de sécurité avec cette solution (le script "setuid" doit faire les vérifications habituelles, e.g. le répertoire .setuid de l'utilisateur en question ne doit pas être world-writable), mais je n'ai pas regardé en détail.
Enfin ça deviens une solution un poil compliquée pour remplacer une fonctionnalité simple :)
Dans l'article <1i8quwb.hw23nx192mpf6N%Nicolas-MICHEL'_remove_'@bluewin.ch>,
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Dans le context d'utilisateurs non admin, on est bien d'accord.
Oui, c'était l'avantage du setuid: une solution adaptée *aussi* aux
utilisateurs non admin.
Mais tu pourrais faire un script "killall -hup tonscript"
et à l'autoriser dans le sudoer pour les utilisateurs donnés.
Oui, mais ça demande une intervention de l'admin. Cela pourrait être
fait une fois pour toutes pour tous les utilisateurs avec un script,
e.g. nommé "setuid", qui va exécuter le programme donné en argument
s'il est dans un répertoire du style "~user/.setuid". Ainsi quand un
utilisateur veut créer un programme avec la fonctionnalité du bit s,
il peut le mettre dans son répertoire ~user/.setuid, et les autres
utilisateurs l'exécutent par:
sudo -u <user> setuid <program> <args>
où <program> est un simple nom de fichier (sans /). Je ne pense pas
qu'il y ait de problème de sécurité avec cette solution (le script
"setuid" doit faire les vérifications habituelles, e.g. le répertoire
.setuid de l'utilisateur en question ne doit pas être world-writable),
mais je n'ai pas regardé en détail.
Enfin ça deviens une solution un poil compliquée pour remplacer une
fonctionnalité simple :)
Dans l'article <1i8quwb.hw23nx192mpf6N%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Dans le context d'utilisateurs non admin, on est bien d'accord.
Oui, c'était l'avantage du setuid: une solution adaptée *aussi* aux utilisateurs non admin.
Mais tu pourrais faire un script "killall -hup tonscript" et à l'autoriser dans le sudoer pour les utilisateurs donnés.
Oui, mais ça demande une intervention de l'admin. Cela pourrait être fait une fois pour toutes pour tous les utilisateurs avec un script, e.g. nommé "setuid", qui va exécuter le programme donné en argument s'il est dans un répertoire du style "~user/.setuid". Ainsi quand un utilisateur veut créer un programme avec la fonctionnalité du bit s, il peut le mettre dans son répertoire ~user/.setuid, et les autres utilisateurs l'exécutent par:
sudo -u <user> setuid <program> <args>
où <program> est un simple nom de fichier (sans /). Je ne pense pas qu'il y ait de problème de sécurité avec cette solution (le script "setuid" doit faire les vérifications habituelles, e.g. le répertoire .setuid de l'utilisateur en question ne doit pas être world-writable), mais je n'ai pas regardé en détail.
Enfin ça deviens une solution un poil compliquée pour remplacer une fonctionnalité simple :)
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Non, sudo vérifie aussi par défaut les arguments, donc les personnes *autorisées* peuvent tuer tous les programmes s'appellant "tonscript", ce qui est en pratique une restriction suffisante.
Vincent Lefevre wrote, On 6/12/07 22:03:
sudo killall -hup tonscript
ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Non, sudo vérifie aussi par défaut les arguments, donc les personnes
*autorisées* peuvent tuer tous les programmes s'appellant "tonscript",
ce qui est en pratique une restriction suffisante.
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Non, sudo vérifie aussi par défaut les arguments, donc les personnes *autorisées* peuvent tuer tous les programmes s'appellant "tonscript", ce qui est en pratique une restriction suffisante.
Vincent Lefevre
Dans l'article <fje04g$dr9$00$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 6/12/07 22:03:
sudo killall -hup tonscript ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Non, sudo vérifie aussi par défaut les arguments, donc les personnes *autorisées* peuvent tuer tous les programmes s'appellant "tonscript", ce qui est en pratique une restriction suffisante.
sauf que mon script a un nom variable et non prévisible. Donc impossible de mettre le nom du script en dur.
Dans l'article <fje04g$dr9$00$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Vincent Lefevre wrote, On 6/12/07 22:03:
sudo killall -hup tonscript
ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Non, sudo vérifie aussi par défaut les arguments, donc les personnes
*autorisées* peuvent tuer tous les programmes s'appellant "tonscript",
ce qui est en pratique une restriction suffisante.
sauf que mon script a un nom variable et non prévisible. Donc
impossible de mettre le nom du script en dur.
Dans l'article <fje04g$dr9$00$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 6/12/07 22:03:
sudo killall -hup tonscript ça ne te plais pas ?
Non. Gros trou de sécurité (n'importe qui peut tuer n'importe quoi).
Non, sudo vérifie aussi par défaut les arguments, donc les personnes *autorisées* peuvent tuer tous les programmes s'appellant "tonscript", ce qui est en pratique une restriction suffisante.
sauf que mon script a un nom variable et non prévisible. Donc impossible de mettre le nom du script en dur.
