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 !
Je sais pas quand tu as essayé, mais cela fait plusieurs années que Linux n'honore pas le setuid sur les scripts par défaut. http://www.google.de/search?q=linux+setuid+scripts
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet article est une preuve que ça fonctionne. :)
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Ca donne quoi si tu fais un: sudo touch /tmp/test
et un script suid root qui fait: rm /tmp/test
?
Vincent Lefevre wrote, On 27/11/07 3:46:
Je sais pas quand tu as essayé, mais cela fait plusieurs années que
Linux n'honore pas le setuid sur les scripts par défaut.
http://www.google.de/search?q=linux+setuid+scripts
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre
inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet
article est une preuve que ça fonctionne. :)
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits
correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Je sais pas quand tu as essayé, mais cela fait plusieurs années que Linux n'honore pas le setuid sur les scripts par défaut. http://www.google.de/search?q=linux+setuid+scripts
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet article est une preuve que ça fonctionne. :)
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Ca donne quoi si tu fais un: sudo touch /tmp/test
et un script suid root qui fait: rm /tmp/test
?
Vincent Lefevre
Dans l'article <fikh8n$k5k$00$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 27/11/07 3:46:
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet article est une preuve que ça fonctionne. :)
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Ils sont honorés, sinon le script ne fonctionnerait pas. Pour info, voici ce que donne ce script sans les bits suid/sgid:
C'est mon script qui permet de poster et récupérer les news (entre
inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet
article est une preuve que ça fonctionne. :)
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits
correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Ils sont honorés, sinon le script ne fonctionnerait pas. Pour info,
voici ce que donne ce script sans les bits suid/sgid:
C'est mon script qui permet de poster et récupérer les news (entre inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet article est une preuve que ça fonctionne. :)
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Ils sont honorés, sinon le script ne fonctionnerait pas. Pour info, voici ce que donne ce script sans les bits suid/sgid:
Je vois que tu testes toujours avec perl, pas avec un shell. En essayant, chez moi, j'ai cette erreur très intéressante: Can't do setuid (cannot exec sperl)
Apparemment, sperl est un programme optionel setuid, appellé par le perl normal quand le script a le bit setuid. C'est une bidouille de perl pour contourner le fait que le bit setuid n'est pas honoré par Linux sur les scripts justement.
Est-ce que tu as ce sperl chez toi? De quel paquet de la distribution fait-il parti?
Vincent Lefevre wrote, On 30/11/07 11:24:
Ben avec les élements que tu donnes, ça prouve seulement que les 2 bits
correspondants sont mis à 1 sur ton fichier, pas qu'ils sont honorés.
Ils sont honorés, sinon le script ne fonctionnerait pas. Pour info,
voici ce que donne ce script sans les bits suid/sgid:
Je vois que tu testes toujours avec perl, pas avec un shell.
En essayant, chez moi, j'ai cette erreur très intéressante:
Can't do setuid (cannot exec sperl)
Apparemment, sperl est un programme optionel setuid, appellé par le perl
normal quand le script a le bit setuid.
C'est une bidouille de perl pour contourner le fait que le bit setuid
n'est pas honoré par Linux sur les scripts justement.
Est-ce que tu as ce sperl chez toi?
De quel paquet de la distribution fait-il parti?
Je vois que tu testes toujours avec perl, pas avec un shell. En essayant, chez moi, j'ai cette erreur très intéressante: Can't do setuid (cannot exec sperl)
Apparemment, sperl est un programme optionel setuid, appellé par le perl normal quand le script a le bit setuid. C'est une bidouille de perl pour contourner le fait que le bit setuid n'est pas honoré par Linux sur les scripts justement.
Est-ce que tu as ce sperl chez toi? De quel paquet de la distribution fait-il parti?
Vincent Lefevre
Dans l'article <firfp6$64a$00$, Olivier Croquette écrit:
Je vois que tu testes toujours avec perl, pas avec un shell.
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne est nécessaire, tout du moins en perl, pour que ça fonctionne).
En essayant, chez moi, j'ai cette erreur très intéressante: Can't do setuid (cannot exec sperl)
Apparemment, sperl est un programme optionel setuid, appellé par le perl normal quand le script a le bit setuid.
C'est une bidouille de perl pour contourner le fait que le bit setuid n'est pas honoré par Linux sur les scripts justement.
Tu as peut-être une version du noyau qui n'accepte pas les scripts setuid. En plus un exécutable perl setuid root alors que les script setuid ne sont pas forcément setuid root, c'est un peu un risque de trou de sécurité.
Dans l'article <firfp6$64a$00$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Je vois que tu testes toujours avec perl, pas avec un shell.
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne
est nécessaire, tout du moins en perl, pour que ça fonctionne).
En essayant, chez moi, j'ai cette erreur très intéressante:
Can't do setuid (cannot exec sperl)
Apparemment, sperl est un programme optionel setuid, appellé par le perl
normal quand le script a le bit setuid.
C'est une bidouille de perl pour contourner le fait que le bit setuid
n'est pas honoré par Linux sur les scripts justement.
Tu as peut-être une version du noyau qui n'accepte pas les scripts setuid.
En plus un exécutable perl setuid root alors que les script setuid ne sont
pas forcément setuid root, c'est un peu un risque de trou de sécurité.
Dans l'article <firfp6$64a$00$, Olivier Croquette écrit:
Je vois que tu testes toujours avec perl, pas avec un shell.
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne est nécessaire, tout du moins en perl, pour que ça fonctionne).
En essayant, chez moi, j'ai cette erreur très intéressante: Can't do setuid (cannot exec sperl)
Apparemment, sperl est un programme optionel setuid, appellé par le perl normal quand le script a le bit setuid.
C'est une bidouille de perl pour contourner le fait que le bit setuid n'est pas honoré par Linux sur les scripts justement.
Tu as peut-être une version du noyau qui n'accepte pas les scripts setuid. En plus un exécutable perl setuid root alors que les script setuid ne sont pas forcément setuid root, c'est un peu un risque de trou de sécurité.
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne est nécessaire, tout du moins en perl, pour que ça fonctionne).
Même si tu pouvais le faire en shell, ça marcherait pas, car le effective user id n'est pas changé par Linux pour les scripts (ie tout ce qui commence par #!).
Tu as peut-être une version du noyau qui n'accepte pas les scripts setuid.
Aucune version standard ("vanilla") du noyau ne le fait!
Mais au début de mon script:
#!/usr/bin/perl -T
C'est bien perl et non sperl5.8.8.
Oui mais ce perl, voyant le setuid de ton script, décide d'appeller sperl (qui a le setuid).
La preuve, c'est que mon script ici utilise aussi /usr/bin/perl, et le setuid, et que j'obtiens un message d'erreur: Can't do setuid (cannot exec sperl)
Tu n'as qu'à renommer ton sperl en sperl.bck, tu verras sûrement que ton script ne marche plus.
La morale, c'est que pour qu'un script marche avec un setuid, il faut que l'intepreteur ait le setuid root, ce qui n'est pas le cas des shells.
Donc, dans le cas général, les scripts setuid ne sont pas possible sous Linux, l'exception de Perl étant du à un "workaround" avec l'interpreteur en setuid.
Vincent Lefevre wrote, On 1/12/07 15:30:
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne
est nécessaire, tout du moins en perl, pour que ça fonctionne).
Même si tu pouvais le faire en shell, ça marcherait pas, car le
effective user id n'est pas changé par Linux pour les scripts (ie tout
ce qui commence par #!).
Tu as peut-être une version du noyau qui n'accepte pas les scripts setuid.
Aucune version standard ("vanilla") du noyau ne le fait!
Mais au début de mon script:
#!/usr/bin/perl -T
C'est bien perl et non sperl5.8.8.
Oui mais ce perl, voyant le setuid de ton script, décide d'appeller
sperl (qui a le setuid).
La preuve, c'est que mon script ici utilise aussi /usr/bin/perl, et le
setuid, et que j'obtiens un message d'erreur:
Can't do setuid (cannot exec sperl)
Tu n'as qu'à renommer ton sperl en sperl.bck, tu verras sûrement que ton
script ne marche plus.
La morale, c'est que pour qu'un script marche avec un setuid, il faut
que l'intepreteur ait le setuid root, ce qui n'est pas le cas des shells.
Donc, dans le cas général, les scripts setuid ne sont pas possible sous
Linux, l'exception de Perl étant du à un "workaround" avec
l'interpreteur en setuid.
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne est nécessaire, tout du moins en perl, pour que ça fonctionne).
Même si tu pouvais le faire en shell, ça marcherait pas, car le effective user id n'est pas changé par Linux pour les scripts (ie tout ce qui commence par #!).
Tu as peut-être une version du noyau qui n'accepte pas les scripts setuid.
Aucune version standard ("vanilla") du noyau ne le fait!
Mais au début de mon script:
#!/usr/bin/perl -T
C'est bien perl et non sperl5.8.8.
Oui mais ce perl, voyant le setuid de ton script, décide d'appeller sperl (qui a le setuid).
La preuve, c'est que mon script ici utilise aussi /usr/bin/perl, et le setuid, et que j'obtiens un message d'erreur: Can't do setuid (cannot exec sperl)
Tu n'as qu'à renommer ton sperl en sperl.bck, tu verras sûrement que ton script ne marche plus.
La morale, c'est que pour qu'un script marche avec un setuid, il faut que l'intepreteur ait le setuid root, ce qui n'est pas le cas des shells.
Donc, dans le cas général, les scripts setuid ne sont pas possible sous Linux, l'exception de Perl étant du à un "workaround" avec l'interpreteur en setuid.
Eric Levenez
Le 1/12/07 15:30, dans <20071201142349$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <firfp6$64a$00$, Olivier Croquette écrit:
Est-ce que tu as ce sperl chez toi?
ay:~> locate sperl /usr/bin/sperl5.8.8
Mais au début de mon script:
#!/usr/bin/perl -T
C'est bien perl et non sperl5.8.8.
Supprime sperl et reteste.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 1/12/07 15:30, dans <20071201142349$6783@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <firfp6$64a$00$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Est-ce que tu as ce sperl chez toi?
ay:~> locate sperl
/usr/bin/sperl5.8.8
Mais au début de mon script:
#!/usr/bin/perl -T
C'est bien perl et non sperl5.8.8.
Supprime sperl et reteste.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 1/12/07 15:30, dans <20071201142349$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <firfp6$64a$00$, Olivier Croquette écrit:
Est-ce que tu as ce sperl chez toi?
ay:~> locate sperl /usr/bin/sperl5.8.8
Mais au début de mon script:
#!/usr/bin/perl -T
C'est bien perl et non sperl5.8.8.
Supprime sperl et reteste.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 1/12/07 16:38, dans <firv6b$v34$01$, « Olivier Croquette » a écrit :
Donc, dans le cas général, les scripts setuid ne sont pas possible sous Linux,
Ni sur de nombreux Unix, comme Mac OS X, heureusement.
l'exception de Perl étant du à un "workaround" avec l'interpreteur en setuid.
Il faut aussi noter que les scripts Perl et sperl ne sont pas compatibles à cause des protections des données externes introduites dans sperl ("données marquées"). Voir le chapitre 23 du bouquin de programmation Perl.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 1/12/07 16:38, dans <firv6b$v34$01$1@news.t-online.com>, « Olivier
Croquette » <ocroquette@ocroquette.free.fr> a écrit :
Donc, dans le cas général, les scripts setuid ne sont pas possible sous
Linux,
Ni sur de nombreux Unix, comme Mac OS X, heureusement.
l'exception de Perl étant du à un "workaround" avec
l'interpreteur en setuid.
Il faut aussi noter que les scripts Perl et sperl ne sont pas compatibles à
cause des protections des données externes introduites dans sperl ("données
marquées"). Voir le chapitre 23 du bouquin de programmation Perl.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 1/12/07 16:38, dans <firv6b$v34$01$, « Olivier Croquette » a écrit :
Donc, dans le cas général, les scripts setuid ne sont pas possible sous Linux,
Ni sur de nombreux Unix, comme Mac OS X, heureusement.
l'exception de Perl étant du à un "workaround" avec l'interpreteur en setuid.
Il faut aussi noter que les scripts Perl et sperl ne sont pas compatibles à cause des protections des données externes introduites dans sperl ("données marquées"). Voir le chapitre 23 du bouquin de programmation Perl.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <firv6b$v34$01$, Olivier Croquette écrit:
Tu n'as qu'à renommer ton sperl en sperl.bck, tu verras sûrement que ton script ne marche plus.
OK, je confirme.
La morale, c'est que pour qu'un script marche avec un setuid, il faut que l'intepreteur ait le setuid root, ce qui n'est pas le cas des shells.
Donc, dans le cas général, les scripts setuid ne sont pas possible sous Linux, l'exception de Perl étant du à un "workaround" avec l'interpreteur en setuid.
Oui, reste que tout ceci est idiot. Si le noyau prenait en compte le bit setuid, il n'y aurait pas besoin de ce workaround. Si ce choix a été fait pour éviter que le neuneu de base fasse des scripts setuid avec des trous de sécurité, j'ai bien peur qu'il essaie de contourner la limitation avec des trous encore plus gros.
Vincent Lefevre wrote, On 1/12/07 15:30:
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne est nécessaire, tout du moins en perl, pour que ça fonctionne).
Même si tu pouvais le faire en shell,
Je me posais la question justement pour pouvoir tester. Et je viens de voir que zsh peut le faire (les variables UID et EUID peuvent être affectées, alors qu'en bash elles sont read-only, d'après le manuel). En fait, il suffisait de tester les valeurs de ces variables.
ça marcherait pas, car le effective user id n'est pas changé par Linux pour les scripts (ie tout ce qui commence par #!).
Oui, je confirme encore. En fait, zsh pourrait faire la même astuce que perl. Maintenant, ce n'est pas moi qui irais écrire un script shell setuid, même s'il ne doit faire qu'une ligne.
Dans l'article <firv6b$v34$01$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Tu n'as qu'à renommer ton sperl en sperl.bck, tu verras sûrement que ton
script ne marche plus.
OK, je confirme.
La morale, c'est que pour qu'un script marche avec un setuid, il faut
que l'intepreteur ait le setuid root, ce qui n'est pas le cas des shells.
Donc, dans le cas général, les scripts setuid ne sont pas possible sous
Linux, l'exception de Perl étant du à un "workaround" avec
l'interpreteur en setuid.
Oui, reste que tout ceci est idiot. Si le noyau prenait en compte le
bit setuid, il n'y aurait pas besoin de ce workaround. Si ce choix a
été fait pour éviter que le neuneu de base fasse des scripts setuid
avec des trous de sécurité, j'ai bien peur qu'il essaie de contourner
la limitation avec des trous encore plus gros.
Vincent Lefevre wrote, On 1/12/07 15:30:
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne
est nécessaire, tout du moins en perl, pour que ça fonctionne).
Même si tu pouvais le faire en shell,
Je me posais la question justement pour pouvoir tester. Et je viens
de voir que zsh peut le faire (les variables UID et EUID peuvent être
affectées, alors qu'en bash elles sont read-only, d'après le manuel).
En fait, il suffisait de tester les valeurs de ces variables.
ça marcherait pas, car le effective user id n'est pas changé par
Linux pour les scripts (ie tout ce qui commence par #!).
Oui, je confirme encore. En fait, zsh pourrait faire la même astuce
que perl. Maintenant, ce n'est pas moi qui irais écrire un script
shell setuid, même s'il ne doit faire qu'une ligne.
Dans l'article <firv6b$v34$01$, Olivier Croquette écrit:
Tu n'as qu'à renommer ton sperl en sperl.bck, tu verras sûrement que ton script ne marche plus.
OK, je confirme.
La morale, c'est que pour qu'un script marche avec un setuid, il faut que l'intepreteur ait le setuid root, ce qui n'est pas le cas des shells.
Donc, dans le cas général, les scripts setuid ne sont pas possible sous Linux, l'exception de Perl étant du à un "workaround" avec l'interpreteur en setuid.
Oui, reste que tout ceci est idiot. Si le noyau prenait en compte le bit setuid, il n'y aurait pas besoin de ce workaround. Si ce choix a été fait pour éviter que le neuneu de base fasse des scripts setuid avec des trous de sécurité, j'ai bien peur qu'il essaie de contourner la limitation avec des trous encore plus gros.
Vincent Lefevre wrote, On 1/12/07 15:30:
Je ne sais pas faire l'équivalent du $< = $> en shell (cette ligne est nécessaire, tout du moins en perl, pour que ça fonctionne).
Même si tu pouvais le faire en shell,
Je me posais la question justement pour pouvoir tester. Et je viens de voir que zsh peut le faire (les variables UID et EUID peuvent être affectées, alors qu'en bash elles sont read-only, d'après le manuel). En fait, il suffisait de tester les valeurs de ces variables.
ça marcherait pas, car le effective user id n'est pas changé par Linux pour les scripts (ie tout ce qui commence par #!).
Oui, je confirme encore. En fait, zsh pourrait faire la même astuce que perl. Maintenant, ce n'est pas moi qui irais écrire un script shell setuid, même s'il ne doit faire qu'une ligne.
