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 !
Dans l'article <C3774398.BDDE7%, Eric Levenez écrit:
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.
Peux-tu en dire plus? Si tu fais allusion au "taint mode", cette fonctionnalité est supportée par du perl standard (et activée par l'option -T ou par le fait qu'un script soit setuid).
Dans l'article <C3774398.BDDE7%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
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.
Peux-tu en dire plus? Si tu fais allusion au "taint mode", cette
fonctionnalité est supportée par du perl standard (et activée par
l'option -T ou par le fait qu'un script soit setuid).
Dans l'article <C3774398.BDDE7%, Eric Levenez écrit:
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.
Peux-tu en dire plus? Si tu fais allusion au "taint mode", cette fonctionnalité est supportée par du perl standard (et activée par l'option -T ou par le fait qu'un script soit 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.
Oui, mais au moins ce sera de sa faute :)
Vincent Lefevre wrote, On 1/12/07 19:18:
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.
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.
Oui, mais au moins ce sera de sa faute :)
Vincent Lefevre
Dans l'article <fisjnd$85v$01$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 1/12/07 19:18:
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.
Oui, mais au moins ce sera de sa faute :)
Dans les deux cas, c'est de sa faute: par défaut, un script (ou autre exécutable) n'est pas setuid.
Dans l'article <fisjnd$85v$01$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Vincent Lefevre wrote, On 1/12/07 19:18:
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.
Oui, mais au moins ce sera de sa faute :)
Dans les deux cas, c'est de sa faute: par défaut, un script (ou autre
exécutable) n'est pas setuid.
Dans l'article <fisjnd$85v$01$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 1/12/07 19:18:
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.
Oui, mais au moins ce sera de sa faute :)
Dans les deux cas, c'est de sa faute: par défaut, un script (ou autre exécutable) n'est pas setuid.
Dans l'article <1i8e9kk.1arwhd21ru6088N%Nicolas-MICHEL'_remove_'@bluewin.ch>, Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> écrit:
Vincent Lefevre <vincent+ wrote:
sudo est destiné à root, alors qu'un utilisateur lambda peut avoir un programme setuid.
Pour configurer un setuid, faut pas être root ?
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Ok, merci. Je réalise en fait que je ne sais pas ce que fait setuid.
Je le confonds avec l'option "(the set-user-ID-on-execution bit)" qu'on trouve dans le man chmod.
Le man setuid est obscure à mes yeux. C'est quoi la différence entre UID effectif, UID réel et UID sauvé ? A quoi sert ce truc, concrêtement ?
%> sudo visudo %staff ALL = NOPASSWD: /usr/bin/pon
et c'est fait. Non ?
Mais tu as besoin des droits de root quelque part pour pouvoir faire ça.
Oui, si on veux.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
laurent.pertois
Vincent Lefevre <vincent+ wrote:
Pour configurer un setuid, faut pas être root ?
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Oui, mais pour en faire un exécutable setuid root il faudra quand même qu'il appartienne à root et donc en transférer la propriété à ce dernier, ce qui nécessite d'être root, chown n'est pas setuid root, que je sache.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Pour configurer un setuid, faut pas être root ?
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Oui, mais pour en faire un exécutable setuid root il faudra quand même
qu'il appartienne à root et donc en transférer la propriété à ce
dernier, ce qui nécessite d'être root, chown n'est pas setuid root, que
je sache.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Oui, mais pour en faire un exécutable setuid root il faudra quand même qu'il appartienne à root et donc en transférer la propriété à ce dernier, ce qui nécessite d'être root, chown n'est pas setuid root, que je sache.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann
In article <1i8jlpy.1vedrxy1i12xpgN%, (Laurent Pertois) wrote:
Vincent Lefevre <vincent+ wrote:
Pour configurer un setuid, faut pas être root ?
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Oui, mais pour en faire un exécutable setuid root il faudra quand même qu'il appartienne à root et donc en transférer la propriété à ce dernier, ce qui nécessite d'être root, chown n'est pas setuid root, que je sache.
Je crois que Vincent faisait justement référence au cas où un utilisateur A veut permettre aux autres utilisateurs de lancer un script comme s'ils étaient A. Si le système supporte les script suid, A peut le faire même s'il n'est qu'un utilisateur normal. Alors que si cela doit être fait en configurant sudo, il ne pourra pas le faire.
Patrick -- Patrick Stadelmann
In article <1i8jlpy.1vedrxy1i12xpgN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Pour configurer un setuid, faut pas être root ?
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Oui, mais pour en faire un exécutable setuid root il faudra quand même
qu'il appartienne à root et donc en transférer la propriété à ce
dernier, ce qui nécessite d'être root, chown n'est pas setuid root, que
je sache.
Je crois que Vincent faisait justement référence au cas où un
utilisateur A veut permettre aux autres utilisateurs de lancer un script
comme s'ils étaient A. Si le système supporte les script suid, A peut le
faire même s'il n'est qu'un utilisateur normal. Alors que si cela doit
être fait en configurant sudo, il ne pourra pas le faire.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1i8jlpy.1vedrxy1i12xpgN%, (Laurent Pertois) wrote:
Vincent Lefevre <vincent+ wrote:
Pour configurer un setuid, faut pas être root ?
Non, pas besoin. Il suffit d'être le propriétaire du programme.
Oui, mais pour en faire un exécutable setuid root il faudra quand même qu'il appartienne à root et donc en transférer la propriété à ce dernier, ce qui nécessite d'être root, chown n'est pas setuid root, que je sache.
Je crois que Vincent faisait justement référence au cas où un utilisateur A veut permettre aux autres utilisateurs de lancer un script comme s'ils étaient A. Si le système supporte les script suid, A peut le faire même s'il n'est qu'un utilisateur normal. Alors que si cela doit être fait en configurant sudo, il ne pourra pas le faire.
Patrick -- Patrick Stadelmann
laurent.pertois
Patrick Stadelmann wrote:
Je crois que Vincent faisait justement référence au cas où un utilisateur A veut permettre aux autres utilisateurs de lancer un script comme s'ils étaient A. Si le système supporte les script suid, A peut le faire même s'il n'est qu'un utilisateur normal. Alors que si cela doit être fait en configurant sudo, il ne pourra pas le faire.
Oui, dans ce cas, on est d'accord...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Je crois que Vincent faisait justement référence au cas où un
utilisateur A veut permettre aux autres utilisateurs de lancer un script
comme s'ils étaient A. Si le système supporte les script suid, A peut le
faire même s'il n'est qu'un utilisateur normal. Alors que si cela doit
être fait en configurant sudo, il ne pourra pas le faire.
Oui, dans ce cas, on est d'accord...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Je crois que Vincent faisait justement référence au cas où un utilisateur A veut permettre aux autres utilisateurs de lancer un script comme s'ils étaient A. Si le système supporte les script suid, A peut le faire même s'il n'est qu'un utilisateur normal. Alors que si cela doit être fait en configurant sudo, il ne pourra pas le faire.
Oui, dans ce cas, on est d'accord...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
blanc
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Je réalise en fait que je ne sais pas ce que fait setuid.
Je le confonds avec l'option "(the set-user-ID-on-execution bit)" qu'on trouve dans le man chmod.
Si, c'est bien de ça qu'on parle : le setuid-bit qu'on peut mettre par la commande chmod. Il permet de faire qu'à l'exécution d'un programme l' utilisateur effectif soit le propriétaire du programme (pas forcément root) et par suite différent de l'utilisateur réel (celui qui a lancé l'exécution). Le programme se retrouve alors avec les droits de l'utilisateur effectif, et peut donc faire des actions (lecture/écriture/exécution) que l'utilisateur réel n'a pas le droit de faire.
Le man setuid est obscure à mes yeux.
Attention, ceci n'est pas tout à fait la même chose : il s'agit de la fonction setuid(), appel système, qui peut être appelée dans un programme C pour modifier l'utilisateur effectif, mais aussi l'utilisateur réel et l'utilisateur sauvé (voir ci-dessous). Quand tu fais "man setuid", tu peux voir sur les lignes d'entête : "SETUID(2)"
Le (2) signifie que tu es dans la section 2 du manuel, c'est-à-dire celle consacrée aux appels systèmes que l'on peut faire depuis un programme C. La section 1, ce sont les commandes Unix. La section 3, ce sont les fonctions des bibliothèques du langage C. ...etc... Chaque section possède une introduction que l'on peut lire par la commande :
man numsec intro avec numsec = numéro de la section.
D'une manière générale, si un mot clef se trouve dans plusieurs sections, il faut préciser celle-ci avant le mot-clef. Par défaut on à la description dans la section la plus basse.
C'est quoi la différence entre UID effectif, UID réel et UID sauvé ? A quoi sert ce truc, concrêtement ?
C'est tout expliqué dans l'intro de la section 2 :
man 2 intro
et tu cherches le mot "real" pour l'utilisateur réel. Les deux autres sont à la suite...
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Je réalise en fait que je ne sais pas ce que fait setuid.
Je le confonds avec l'option "(the set-user-ID-on-execution bit)"
qu'on trouve dans le man chmod.
Si, c'est bien de ça qu'on parle : le setuid-bit qu'on peut mettre par
la commande chmod. Il permet de faire qu'à l'exécution d'un programme l'
utilisateur effectif soit le propriétaire du programme (pas forcément
root) et par suite différent de l'utilisateur réel (celui qui a lancé
l'exécution). Le programme se retrouve alors avec les droits de
l'utilisateur effectif, et peut donc faire des actions
(lecture/écriture/exécution) que l'utilisateur réel n'a pas le droit de
faire.
Le man setuid est obscure à mes yeux.
Attention, ceci n'est pas tout à fait la même chose : il s'agit de la
fonction setuid(), appel système, qui peut être appelée dans un
programme C pour modifier l'utilisateur effectif, mais aussi
l'utilisateur réel et l'utilisateur sauvé (voir ci-dessous). Quand tu
fais "man setuid", tu peux voir sur les lignes d'entête : "SETUID(2)"
Le (2) signifie que tu es dans la section 2 du manuel, c'est-à-dire
celle consacrée aux appels systèmes que l'on peut faire depuis un
programme C.
La section 1, ce sont les commandes Unix.
La section 3, ce sont les fonctions des bibliothèques du langage C.
...etc...
Chaque section possède une introduction que l'on peut lire par la
commande :
man numsec intro
avec numsec = numéro de la section.
D'une manière générale, si un mot clef se trouve dans plusieurs
sections, il faut préciser celle-ci avant le mot-clef. Par défaut on à
la description dans la section la plus basse.
C'est quoi la différence entre UID effectif, UID réel et UID sauvé ?
A quoi sert ce truc, concrêtement ?
C'est tout expliqué dans l'intro de la section 2 :
man 2 intro
et tu cherches le mot "real" pour l'utilisateur réel. Les deux autres
sont à la suite...
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Je réalise en fait que je ne sais pas ce que fait setuid.
Je le confonds avec l'option "(the set-user-ID-on-execution bit)" qu'on trouve dans le man chmod.
Si, c'est bien de ça qu'on parle : le setuid-bit qu'on peut mettre par la commande chmod. Il permet de faire qu'à l'exécution d'un programme l' utilisateur effectif soit le propriétaire du programme (pas forcément root) et par suite différent de l'utilisateur réel (celui qui a lancé l'exécution). Le programme se retrouve alors avec les droits de l'utilisateur effectif, et peut donc faire des actions (lecture/écriture/exécution) que l'utilisateur réel n'a pas le droit de faire.
Le man setuid est obscure à mes yeux.
Attention, ceci n'est pas tout à fait la même chose : il s'agit de la fonction setuid(), appel système, qui peut être appelée dans un programme C pour modifier l'utilisateur effectif, mais aussi l'utilisateur réel et l'utilisateur sauvé (voir ci-dessous). Quand tu fais "man setuid", tu peux voir sur les lignes d'entête : "SETUID(2)"
Le (2) signifie que tu es dans la section 2 du manuel, c'est-à-dire celle consacrée aux appels systèmes que l'on peut faire depuis un programme C. La section 1, ce sont les commandes Unix. La section 3, ce sont les fonctions des bibliothèques du langage C. ...etc... Chaque section possède une introduction que l'on peut lire par la commande :
man numsec intro avec numsec = numéro de la section.
D'une manière générale, si un mot clef se trouve dans plusieurs sections, il faut préciser celle-ci avant le mot-clef. Par défaut on à la description dans la section la plus basse.
C'est quoi la différence entre UID effectif, UID réel et UID sauvé ? A quoi sert ce truc, concrêtement ?
C'est tout expliqué dans l'intro de la section 2 :
man 2 intro
et tu cherches le mot "real" pour l'utilisateur réel. Les deux autres sont à la suite...
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Nicolas-MICHEL'_remove_'
JiPaul wrote:
Si, c'est bien de ça qu'on parle : le setuid-bit qu'on peut mettre par la commande chmod. Il permet de faire qu'à l'exécution d'un programme l' utilisateur effectif soit le propriétaire du programme (pas forcément root) et par suite différent de l'utilisateur réel (celui qui a lancé l'exécution). Le programme se retrouve alors avec les droits de l'utilisateur effectif, et peut donc faire des actions (lecture/écriture/exécution) que l'utilisateur réel n'a pas le droit de faire.
Ok, je comprends ce que tu veux faire. N'ayant jamais eu un tel besoins je n'ai pas tilté.
Mais bon c'est logique, on interdit l'accès direct à des données d'un côté et de l'autre on l'autorise via l'utilisation d'un script ... ça peut être pratique.
Ceci dit immaginer faire ça sur un post dont on est pas admin, je vois mal ... Sur un serveur web éventuellement ?
Le man setuid est obscure à mes yeux.
Attention, ceci n'est pas tout à fait la même chose : il s'agit de la fonction setuid(), appel système, qui peut être appelée dans un programme C pour modifier l'utilisateur effectif, mais aussi l'utilisateur réel et l'utilisateur sauvé (voir ci-dessous). Quand tu fais "man setuid", tu peux voir sur les lignes d'entête : "SETUID(2)"
Le (2) signifie que tu es dans la section 2 du manuel, c'est-à-dire celle consacrée aux appels systèmes que l'on peut faire depuis un programme C.
[snip] Ok, man man ça j'ai déjà fait :)
C'est quoi la différence entre UID effectif, UID réel et UID sauvé ? A quoi sert ce truc, concrêtement ?
C'est tout expliqué dans l'intro de la section 2 :
man 2 intro
et tu cherches le mot "real" pour l'utilisateur réel. Les deux autres sont à la suite...
Tu est sur quel système ? Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne me renseignent à ce sujet.
Mais c'est pas grave, c'était juste de la curiosité.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
JiPaul <blanc@empty.org> wrote:
Si, c'est bien de ça qu'on parle : le setuid-bit qu'on peut mettre par
la commande chmod. Il permet de faire qu'à l'exécution d'un programme l'
utilisateur effectif soit le propriétaire du programme (pas forcément
root) et par suite différent de l'utilisateur réel (celui qui a lancé
l'exécution). Le programme se retrouve alors avec les droits de
l'utilisateur effectif, et peut donc faire des actions
(lecture/écriture/exécution) que l'utilisateur réel n'a pas le droit de
faire.
Ok, je comprends ce que tu veux faire.
N'ayant jamais eu un tel besoins je n'ai pas tilté.
Mais bon c'est logique, on interdit l'accès direct à des données d'un
côté et de l'autre on l'autorise via l'utilisation d'un script ...
ça peut être pratique.
Ceci dit immaginer faire ça sur un post dont on est pas admin, je vois
mal ... Sur un serveur web éventuellement ?
Le man setuid est obscure à mes yeux.
Attention, ceci n'est pas tout à fait la même chose : il s'agit de la
fonction setuid(), appel système, qui peut être appelée dans un
programme C pour modifier l'utilisateur effectif, mais aussi
l'utilisateur réel et l'utilisateur sauvé (voir ci-dessous). Quand tu
fais "man setuid", tu peux voir sur les lignes d'entête : "SETUID(2)"
Le (2) signifie que tu es dans la section 2 du manuel, c'est-à-dire
celle consacrée aux appels systèmes que l'on peut faire depuis un
programme C.
[snip]
Ok, man man ça j'ai déjà fait :)
C'est quoi la différence entre UID effectif, UID réel et UID sauvé ?
A quoi sert ce truc, concrêtement ?
C'est tout expliqué dans l'intro de la section 2 :
man 2 intro
et tu cherches le mot "real" pour l'utilisateur réel. Les deux autres
sont à la suite...
Tu est sur quel système ?
Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne
me renseignent à ce sujet.
Mais c'est pas grave, c'était juste de la curiosité.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Si, c'est bien de ça qu'on parle : le setuid-bit qu'on peut mettre par la commande chmod. Il permet de faire qu'à l'exécution d'un programme l' utilisateur effectif soit le propriétaire du programme (pas forcément root) et par suite différent de l'utilisateur réel (celui qui a lancé l'exécution). Le programme se retrouve alors avec les droits de l'utilisateur effectif, et peut donc faire des actions (lecture/écriture/exécution) que l'utilisateur réel n'a pas le droit de faire.
Ok, je comprends ce que tu veux faire. N'ayant jamais eu un tel besoins je n'ai pas tilté.
Mais bon c'est logique, on interdit l'accès direct à des données d'un côté et de l'autre on l'autorise via l'utilisation d'un script ... ça peut être pratique.
Ceci dit immaginer faire ça sur un post dont on est pas admin, je vois mal ... Sur un serveur web éventuellement ?
Le man setuid est obscure à mes yeux.
Attention, ceci n'est pas tout à fait la même chose : il s'agit de la fonction setuid(), appel système, qui peut être appelée dans un programme C pour modifier l'utilisateur effectif, mais aussi l'utilisateur réel et l'utilisateur sauvé (voir ci-dessous). Quand tu fais "man setuid", tu peux voir sur les lignes d'entête : "SETUID(2)"
Le (2) signifie que tu es dans la section 2 du manuel, c'est-à-dire celle consacrée aux appels systèmes que l'on peut faire depuis un programme C.
[snip] Ok, man man ça j'ai déjà fait :)
C'est quoi la différence entre UID effectif, UID réel et UID sauvé ? A quoi sert ce truc, concrêtement ?
C'est tout expliqué dans l'intro de la section 2 :
man 2 intro
et tu cherches le mot "real" pour l'utilisateur réel. Les deux autres sont à la suite...
Tu est sur quel système ? Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne me renseignent à ce sujet.
Mais c'est pas grave, c'était juste de la curiosité.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Vincent Lefevre
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. 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).
Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne me renseignent à ce sujet.
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.
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).
Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne
me renseignent à ce sujet.
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. 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).
Ici, ni Mac OS X 10.4 ni CentOS ni les man pages françaises de linux ne me renseignent à ce sujet.
