Bonjour,
J'ai fais une bêtise et je ne vois pas comment la réparer. Si vous pouviez
m'aider...
J'ai Aurox 9.3. C'est une base RedHat.
Pour activer et désactiver le réseau, il me faut appeler
/usr/bin/redhat-config-network qui est un lien symbolique vers
consolehelper et donner le mot de passe de su.
Je suis seul à utiliser ma machine donc, pour me débarrasser du mot de
passe, j'ai fait
chmod +s redhat-config-network
Avec ls -l, aucun s dans les autorisations de ce lien. En revanche, le s est
(apparaît ???) pour consolehelper.
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers
consolehelper donc anomalie :
[normal@localhost bin]$ ls -l redhat-con*
lrwxrwxrwx 1 root root 13 avr 18 13:41
redhat-config-authentication -> consolehelper
lrwxrwxrwx 1 root root 13 avr 18 13:41 redhat-config-date
-> consolehelper
etc pour la floppée de liens symboliques.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
[root@localhost bin]# ls -l consolehelper
-r-sr-sr-x 1 root root 5288 avr 20 17:38 consolehelper
Ici encore, consolehelper apparaît en rouge, donc problème ! J'ai essayé de
remettre les autorisations d'avant :
chmod +x redhat-config-network
ou
chmod +x consolhelper, rien n'y fait.
Alors, si vous aviez une solution, je vous en serais bien reconnaissant.
Bonne soirée,
Dominique
Le Sun, 18 Jul 2004 00:09:11 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
http://magnolia.tichou.org/~tichou/dircolors.png
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Khanh-Dang
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Ne vous énervez pas pour un malheureux malentendu ;)
Ronald voulait dire que les liens symboliques sont toujours affichés en cyan, quel que soit les propriétés du fichier vers lequel il pointe. Il n'ont donc pas la même couleur. Son point de vue étant celui-ci : Si dans /usr/bin on fait un ls sans son option -l, on reconnaitra tout de même les liens symboliques puisqu'ils sont en cyan.
Voilà voilà...
-- Khanh-Dang, http://kd.fr.st
Moi je vois pwet en cyan qui pointe vers ping en gris surligné
en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Ne vous énervez pas pour un malheureux malentendu ;)
Ronald voulait dire que les liens symboliques sont toujours affichés en
cyan, quel que soit les propriétés du fichier vers lequel il pointe. Il
n'ont donc pas la même couleur.
Son point de vue étant celui-ci :
Si dans /usr/bin on fait un ls sans son option -l, on reconnaitra tout
de même les liens symboliques puisqu'ils sont en cyan.
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Ne vous énervez pas pour un malheureux malentendu ;)
Ronald voulait dire que les liens symboliques sont toujours affichés en cyan, quel que soit les propriétés du fichier vers lequel il pointe. Il n'ont donc pas la même couleur. Son point de vue étant celui-ci : Si dans /usr/bin on fait un ls sans son option -l, on reconnaitra tout de même les liens symboliques puisqu'ils sont en cyan.
Voilà voilà...
-- Khanh-Dang, http://kd.fr.st
Ronald
Le Sun, 18 Jul 2004 00:13:40 +0200, Khanh-Dang a écrit :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Ne vous énervez pas pour un malheureux malentendu ;)
Ronald voulait dire que les liens symboliques sont toujours affichés en cyan, quel que soit les propriétés du fichier vers lequel il pointe. Il n'ont donc pas la même couleur.
Voilà, merci, j'avais peur de na pas m'être correctement exprimer, peut être était ce la cas.
Le Sun, 18 Jul 2004 00:13:40 +0200, Khanh-Dang a écrit :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné
en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Ne vous énervez pas pour un malheureux malentendu ;)
Ronald voulait dire que les liens symboliques sont toujours affichés en
cyan, quel que soit les propriétés du fichier vers lequel il pointe. Il
n'ont donc pas la même couleur.
Voilà, merci, j'avais peur de na pas m'être correctement exprimer, peut
être était ce la cas.
Le Sun, 18 Jul 2004 00:13:40 +0200, Khanh-Dang a écrit :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Ne vous énervez pas pour un malheureux malentendu ;)
Ronald voulait dire que les liens symboliques sont toujours affichés en cyan, quel que soit les propriétés du fichier vers lequel il pointe. Il n'ont donc pas la même couleur.
Voilà, merci, j'avais peur de na pas m'être correctement exprimer, peut être était ce la cas.
TiChou
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Dans le poste initial, Dominique nous parlait de la couleur de son lien symbolique qui apparaissait au rouge quand le fichier source était setuid. Dans la réponse que je lui ai faite et à laquelle vous êtes intervenu, quand je lui parlais de la couleur des liens symboliques, pensez vous que je faisais référence à ce qu'il signalait ou à autre chose, ou plus précisément à la couleur de la cible (partie droite dans l'affichage de ls) ou de la destination (partie gauche) du lien ? Alors effectivement, si vous ne parliez *que* de la couleur de la destination, je commence alors à comprendre le quiproquo.
Alors pour vous répondre, non, pwet n'est pas de la même couleur que ping. Mais la commande 'ls' affiche bien la couleur de la cible du lien de la même couleur que le fichier source, non ? Et je suis persuadé que c'est bien de cela que Dominique parlait, car d'ailleurs je ne vois pas de quoi d'autre il pourrait s'agir.
Bref, je crois que maintenant nous sommes bien d'accord et désolé s'il s'agissait bien d'un quiproquo.
-- TiChou
Dans le message <news:pan.2004.07.17.22.13.19.62290@reply.to>,
*Ronald* tapota sur f.c.o.l.configuration :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en
rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus,
il faut noter que la commande 'ls' affiche les liens symboliques de la
même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Dans le poste initial, Dominique nous parlait de la couleur de son lien
symbolique qui apparaissait au rouge quand le fichier source était setuid.
Dans la réponse que je lui ai faite et à laquelle vous êtes intervenu, quand
je lui parlais de la couleur des liens symboliques, pensez vous que je
faisais référence à ce qu'il signalait ou à autre chose, ou plus précisément
à la couleur de la cible (partie droite dans l'affichage de ls) ou de la
destination (partie gauche) du lien ? Alors effectivement, si vous ne
parliez *que* de la couleur de la destination, je commence alors à
comprendre le quiproquo.
Alors pour vous répondre, non, pwet n'est pas de la même couleur que ping.
Mais la commande 'ls' affiche bien la couleur de la cible du lien de la même
couleur que le fichier source, non ? Et je suis persuadé que c'est bien de
cela que Dominique parlait, car d'ailleurs je ne vois pas de quoi d'autre il
pourrait s'agir.
Bref, je crois que maintenant nous sommes bien d'accord et désolé s'il
s'agissait bien d'un quiproquo.
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Dans le poste initial, Dominique nous parlait de la couleur de son lien symbolique qui apparaissait au rouge quand le fichier source était setuid. Dans la réponse que je lui ai faite et à laquelle vous êtes intervenu, quand je lui parlais de la couleur des liens symboliques, pensez vous que je faisais référence à ce qu'il signalait ou à autre chose, ou plus précisément à la couleur de la cible (partie droite dans l'affichage de ls) ou de la destination (partie gauche) du lien ? Alors effectivement, si vous ne parliez *que* de la couleur de la destination, je commence alors à comprendre le quiproquo.
Alors pour vous répondre, non, pwet n'est pas de la même couleur que ping. Mais la commande 'ls' affiche bien la couleur de la cible du lien de la même couleur que le fichier source, non ? Et je suis persuadé que c'est bien de cela que Dominique parlait, car d'ailleurs je ne vois pas de quoi d'autre il pourrait s'agir.
Bref, je crois que maintenant nous sommes bien d'accord et désolé s'il s'agissait bien d'un quiproquo.
-- TiChou
Ronald
Le Sun, 18 Jul 2004 00:37:31 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Dans le poste initial, Dominique nous parlait de la couleur de son lien symbolique qui apparaissait au rouge quand le fichier source était setuid. Dans la réponse que je lui ai faite et à laquelle vous êtes intervenu, quand je lui parlais de la couleur des liens symboliques, pensez vous que je faisais référence à ce qu'il signalait ou à autre chose, ou plus précisément à la couleur de la cible (partie droite dans l'affichage de ls) ou de la destination (partie gauche) du lien ? Alors effectivement, si vous ne parliez *que* de la couleur de la destination, je commence alors à comprendre le quiproquo.
Alors pour vous répondre, non, pwet n'est pas de la même couleur que ping. Mais la commande 'ls' affiche bien la couleur de la cible du lien de la même couleur que le fichier source, non ? Et je suis persuadé que c'est bien de cela que Dominique parlait, car d'ailleurs je ne vois pas de quoi d'autre il pourrait s'agir.
Bref, je crois que maintenant nous sommes bien d'accord et désolé s'il s'agissait bien d'un quiproquo.
D'accord, oui, il s'agit bien d'un quiproquo. Désolé. Remarque: il pourrait aussi s'agir d'un lien orphelin qui apparaît en rouge parce que ne pointant vers aucun exécutables existant.
Le Sun, 18 Jul 2004 00:37:31 +0200, TiChou a écrit :
Dans le message <news:pan.2004.07.17.22.13.19.62290@reply.to>, *Ronald*
tapota sur f.c.o.l.configuration :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en
rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus,
il faut noter que la commande 'ls' affiche les liens symboliques de la
même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Dans le poste initial, Dominique nous parlait de la couleur de son lien
symbolique qui apparaissait au rouge quand le fichier source était
setuid. Dans la réponse que je lui ai faite et à laquelle vous êtes
intervenu, quand je lui parlais de la couleur des liens symboliques,
pensez vous que je faisais référence à ce qu'il signalait ou à autre
chose, ou plus précisément à la couleur de la cible (partie droite dans
l'affichage de ls) ou de la destination (partie gauche) du lien ? Alors
effectivement, si vous ne parliez *que* de la couleur de la destination,
je commence alors à comprendre le quiproquo.
Alors pour vous répondre, non, pwet n'est pas de la même couleur que
ping. Mais la commande 'ls' affiche bien la couleur de la cible du lien de
la même couleur que le fichier source, non ? Et je suis persuadé que
c'est bien de cela que Dominique parlait, car d'ailleurs je ne vois pas de
quoi d'autre il pourrait s'agir.
Bref, je crois que maintenant nous sommes bien d'accord et désolé s'il
s'agissait bien d'un quiproquo.
D'accord, oui, il s'agit bien d'un quiproquo.
Désolé.
Remarque: il pourrait aussi s'agir d'un lien orphelin qui
apparaît en rouge parce que ne pointant vers aucun exécutables existant.
Le Sun, 18 Jul 2004 00:37:31 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Moi je vois pwet en cyan qui pointe vers ping en gris surligné en rouge, il faut peut être que je consulte un oculiste, alors?
Vous le faites exprès ?
Attends, je ne suis plus sur là:
De plus, il faut noter que la commande 'ls' affiche les liens symboliques de la même couleur que leur fichier source.
pwet n'est PAS de la même couleur que ping, oui ou non?
Dans le poste initial, Dominique nous parlait de la couleur de son lien symbolique qui apparaissait au rouge quand le fichier source était setuid. Dans la réponse que je lui ai faite et à laquelle vous êtes intervenu, quand je lui parlais de la couleur des liens symboliques, pensez vous que je faisais référence à ce qu'il signalait ou à autre chose, ou plus précisément à la couleur de la cible (partie droite dans l'affichage de ls) ou de la destination (partie gauche) du lien ? Alors effectivement, si vous ne parliez *que* de la couleur de la destination, je commence alors à comprendre le quiproquo.
Alors pour vous répondre, non, pwet n'est pas de la même couleur que ping. Mais la commande 'ls' affiche bien la couleur de la cible du lien de la même couleur que le fichier source, non ? Et je suis persuadé que c'est bien de cela que Dominique parlait, car d'ailleurs je ne vois pas de quoi d'autre il pourrait s'agir.
Bref, je crois que maintenant nous sommes bien d'accord et désolé s'il s'agissait bien d'un quiproquo.
D'accord, oui, il s'agit bien d'un quiproquo. Désolé. Remarque: il pourrait aussi s'agir d'un lien orphelin qui apparaît en rouge parce que ne pointant vers aucun exécutables existant.
Dominique
Bonjour,
Normal. Les permissions sur un lien symbolique n'ont aucun effet.
Eh bien ! j'aurai appris quelque chose, aujourd'hui. J'ignorais ce point des permissions.
En revanche, le s est (apparaît ???) pour consolehelper.
Normal et logique, non ?
Je suppose que oui si je l'ai demandé. Ce qui me laisse perplexe, c'est que les autorisations données à un lien symbolique impactent directement l'exécutable pointé !
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers consolehelper donc anomalie :
Pourquoi anomalie ? Exact. Ma confusion vient de ce qu'Aurox affiche en rouge clignotant les
liens erronés. Visiblement, les liens symboliques setuid sont rouges, les liens symboliques normaux sont verts.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
Certainement du à une protection au niveau de KDE ou au niveau de la commande consolhelper qui empêche l'exécution de ce programme s'il est setuid.
Exact. J'ai fait, comme vous me l'indiquez plus bas, chmod -s consolhelper et tout est rentré dans l'ordre avec KDE.
Mais il aurait été intéressant que vous nous disiez exactement ce qui se passe quand vous tentez de lancer ce programme. Message d'erreur ? Log ? Il ne se passe rien ! KDE pédale et ne dit rien. Depuis une console, j'ai un
message d'erreur qui, à mon sens n'a rien à voir :
[ normal]# /usr/bin/redhat-config-network
(redhat-config-network:2149): libglade-WARNING **: unknown property `xstock_item' for class `GtkImageMenuItem'
J'ai essayé de remettre les autorisations d'avant : chmod +x redhat-config-network
La logique voudrait que vous fassiez la commande inverse de celle que vous aviez tapez précédemment... +s devenant -s, logique, non ? :) Donc :
$ chmod -s redhat-config-network
Je crois que j'ai eu une grosse panne de logique...
Une lecture des deux sites suivant vous aidera à mieux maîtriser la gestion des permissions :
Je vous remercie pour ces liens. Je confirme avoir quelques difficultés avec les permissions.
Mais bon, la question que je me pose c'est pourquoi vouloir activer et désactiver le réseau ? Cela cacherait-il un autre problème qui alors serait plus judicieux de résoudre que de vouloir s'en sortir par un tour de passe-passe ?
J'ai un routeur ADSL ethernet que je partage avec mon fils (pas de hub, il a son PC, moi le mien). Pour me déconnecter proprement, je désactive le réseau sans arrêter mon ordinateur. Je réactive le réseau de la même mmanière sans rebooter. C'est simple et propre. Seul "inconvénient" : le mot de passe root.
Je vous remercie et vous souhaite un excellent dimanche, Dominique
Bonjour,
Normal. Les permissions sur un lien symbolique n'ont aucun effet.
Eh bien ! j'aurai appris quelque chose, aujourd'hui. J'ignorais ce point des
permissions.
En revanche, le s est (apparaît ???) pour consolehelper.
Normal et logique, non ?
Je suppose que oui si je l'ai demandé. Ce qui me laisse perplexe, c'est que
les autorisations données à un lien symbolique impactent directement
l'exécutable pointé !
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers
consolehelper donc anomalie :
Pourquoi anomalie ?
Exact. Ma confusion vient de ce qu'Aurox affiche en rouge clignotant les
liens erronés. Visiblement, les liens symboliques setuid sont rouges, les
liens symboliques normaux sont verts.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
Certainement du à une protection au niveau de KDE ou au niveau de la
commande consolhelper qui empêche l'exécution de ce programme s'il est
setuid.
Exact. J'ai fait, comme vous me l'indiquez plus bas, chmod -s consolhelper
et tout est rentré dans l'ordre avec KDE.
Mais il aurait été intéressant que vous nous disiez exactement ce qui se
passe quand vous tentez de lancer ce programme. Message d'erreur ? Log ?
Il ne se passe rien ! KDE pédale et ne dit rien. Depuis une console, j'ai un
message d'erreur qui, à mon sens n'a rien à voir :
Je vous remercie pour ces liens. Je confirme avoir quelques difficultés avec
les permissions.
Mais bon, la question que je me pose c'est pourquoi vouloir activer et
désactiver le réseau ? Cela cacherait-il un autre problème qui alors
serait plus judicieux de résoudre que de vouloir s'en sortir par un tour
de passe-passe ?
J'ai un routeur ADSL ethernet que je partage avec mon fils (pas de hub, il a
son PC, moi le mien). Pour me déconnecter proprement, je désactive le
réseau sans arrêter mon ordinateur. Je réactive le réseau de la même
mmanière sans rebooter. C'est simple et propre. Seul "inconvénient" : le
mot de passe root.
Je vous remercie et vous souhaite un excellent dimanche,
Dominique
Normal. Les permissions sur un lien symbolique n'ont aucun effet.
Eh bien ! j'aurai appris quelque chose, aujourd'hui. J'ignorais ce point des permissions.
En revanche, le s est (apparaît ???) pour consolehelper.
Normal et logique, non ?
Je suppose que oui si je l'ai demandé. Ce qui me laisse perplexe, c'est que les autorisations données à un lien symbolique impactent directement l'exécutable pointé !
un ls-l redhat-config* m'affiche en rouge tous les liens symboliques vers consolehelper donc anomalie :
Pourquoi anomalie ? Exact. Ma confusion vient de ce qu'Aurox affiche en rouge clignotant les
liens erronés. Visiblement, les liens symboliques setuid sont rouges, les liens symboliques normaux sont verts.
Je n'ai plus accès à consolhelper depuis KDE en mode utilisateur.
Certainement du à une protection au niveau de KDE ou au niveau de la commande consolhelper qui empêche l'exécution de ce programme s'il est setuid.
Exact. J'ai fait, comme vous me l'indiquez plus bas, chmod -s consolhelper et tout est rentré dans l'ordre avec KDE.
Mais il aurait été intéressant que vous nous disiez exactement ce qui se passe quand vous tentez de lancer ce programme. Message d'erreur ? Log ? Il ne se passe rien ! KDE pédale et ne dit rien. Depuis une console, j'ai un
message d'erreur qui, à mon sens n'a rien à voir :
[ normal]# /usr/bin/redhat-config-network
(redhat-config-network:2149): libglade-WARNING **: unknown property `xstock_item' for class `GtkImageMenuItem'
J'ai essayé de remettre les autorisations d'avant : chmod +x redhat-config-network
La logique voudrait que vous fassiez la commande inverse de celle que vous aviez tapez précédemment... +s devenant -s, logique, non ? :) Donc :
$ chmod -s redhat-config-network
Je crois que j'ai eu une grosse panne de logique...
Une lecture des deux sites suivant vous aidera à mieux maîtriser la gestion des permissions :
Je vous remercie pour ces liens. Je confirme avoir quelques difficultés avec les permissions.
Mais bon, la question que je me pose c'est pourquoi vouloir activer et désactiver le réseau ? Cela cacherait-il un autre problème qui alors serait plus judicieux de résoudre que de vouloir s'en sortir par un tour de passe-passe ?
J'ai un routeur ADSL ethernet que je partage avec mon fils (pas de hub, il a son PC, moi le mien). Pour me déconnecter proprement, je désactive le réseau sans arrêter mon ordinateur. Je réactive le réseau de la même mmanière sans rebooter. C'est simple et propre. Seul "inconvénient" : le mot de passe root.
Je vous remercie et vous souhaite un excellent dimanche, Dominique
