J'ai découvert avec plaisir sur MacOS X l'application "terminal" qui me
donne accès à un shell, mais comment faire pour devenir root ?? la
commande su me demande le password de root et ce n'est pas le meme que le
mien :-( Je suis pourtant administrateur de la machine nom de ... !!
Vu comme ça, 90% des utilisateurs (ceux du premier type) n'ont absolument aucun intérêt d'activer le compte root. Les autres peuvent trouver que ça un intérêt (je trouve qu'utiliser le compte root est plus simple que de créer un utilisateur admin).
je vois pas en quoi c'est plus simple, mais bon...
Vu comme ça, 90% des utilisateurs (ceux du premier type) n'ont
absolument aucun intérêt d'activer le compte root. Les autres peuvent
trouver que ça un intérêt (je trouve qu'utiliser le compte root est plus
simple que de créer un utilisateur admin).
je vois pas en quoi c'est plus simple, mais bon...
Vu comme ça, 90% des utilisateurs (ceux du premier type) n'ont absolument aucun intérêt d'activer le compte root. Les autres peuvent trouver que ça un intérêt (je trouve qu'utiliser le compte root est plus simple que de créer un utilisateur admin).
je vois pas en quoi c'est plus simple, mais bon...
Et si on vire celui qui a le mot de passe root ? Hein ?
Si y'a pas de compte root d'activé, y'a pas d'admin qui a le mot de passe root.
Comment tu fais tes scripts d'administration qui se connecte à distance ?
Plusieurs solutions... ARD est la plus simple.
Appel Remode Display ? Pour des scripts ?
Jouer avec l'encodage/décodage du mot de passe avec redirection des sortie en est une autre...
???
Tu peux aussi dire à sudo de ne pas demander de mot de passe pour une commande particulière, c'est encore une autre solution...
Je me suis fait mal comprendre : pour exécuter sur 90 clients une commandes à distance, sur une crontab par exemple.
En fait cela revient de toutes façons à utiliser root.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
jayce@mosx.net (Anonyme) writes:
FiLH <filh@filh.org> wrote:
jayce@mosx.net (Anonyme) writes:
FiLH <filh@filh.org> wrote:
Et si on vire celui qui a le mot de passe root ? Hein ?
Si y'a pas de compte root d'activé, y'a pas d'admin qui a le mot de
passe root.
Comment tu fais tes scripts d'administration qui se connecte à
distance ?
Plusieurs solutions...
ARD est la plus simple.
Appel Remode Display ? Pour des scripts ?
Jouer avec l'encodage/décodage du mot de passe avec redirection des
sortie en est une autre...
???
Tu peux aussi dire à sudo de ne pas demander de mot de passe pour une
commande particulière, c'est encore une autre solution...
Je me suis fait mal comprendre : pour exécuter sur 90 clients une
commandes à distance, sur une crontab par exemple.
En fait cela revient de toutes façons à utiliser root.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Et si on vire celui qui a le mot de passe root ? Hein ?
Si y'a pas de compte root d'activé, y'a pas d'admin qui a le mot de passe root.
Comment tu fais tes scripts d'administration qui se connecte à distance ?
Plusieurs solutions... ARD est la plus simple.
Appel Remode Display ? Pour des scripts ?
Jouer avec l'encodage/décodage du mot de passe avec redirection des sortie en est une autre...
???
Tu peux aussi dire à sudo de ne pas demander de mot de passe pour une commande particulière, c'est encore une autre solution...
Je me suis fait mal comprendre : pour exécuter sur 90 clients une commandes à distance, sur une crontab par exemple.
En fait cela revient de toutes façons à utiliser root.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
laurent.pertois
FiLH wrote:
ARD est la plus simple.
Appel Remode Display ? Pour des scripts ?
Apple Remote Desktop, dont l'une des fonctions est la possibilité d'afficher à distance l'écran d'une machine (comme vnc) mais ça n'est pas la seule, loin de là, c'est même, à mon avis, la moins intéressante de ses fonctionnalités. Par exemple, tu peux sélectionner toutes tes stations (ou certaines) et exécuter un script (que tu tapes dans la fenêtre, ou que tu copies-colles, donc pas besoin de l'avoir recopié sur les stations et donc de le synchroniser à chaque changement), ce dernier sera exécuté par un utilisateur particulier ou par celui qui a les droits d'administration ARD.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
FiLH <filh@filh.org> wrote:
ARD est la plus simple.
Appel Remode Display ? Pour des scripts ?
Apple Remote Desktop, dont l'une des fonctions est la possibilité
d'afficher à distance l'écran d'une machine (comme vnc) mais ça n'est
pas la seule, loin de là, c'est même, à mon avis, la moins intéressante
de ses fonctionnalités. Par exemple, tu peux sélectionner toutes tes
stations (ou certaines) et exécuter un script (que tu tapes dans la
fenêtre, ou que tu copies-colles, donc pas besoin de l'avoir recopié sur
les stations et donc de le synchroniser à chaque changement), ce dernier
sera exécuté par un utilisateur particulier ou par celui qui a les
droits d'administration ARD.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Apple Remote Desktop, dont l'une des fonctions est la possibilité d'afficher à distance l'écran d'une machine (comme vnc) mais ça n'est pas la seule, loin de là, c'est même, à mon avis, la moins intéressante de ses fonctionnalités. Par exemple, tu peux sélectionner toutes tes stations (ou certaines) et exécuter un script (que tu tapes dans la fenêtre, ou que tu copies-colles, donc pas besoin de l'avoir recopié sur les stations et donc de le synchroniser à chaque changement), ce dernier sera exécuté par un utilisateur particulier ou par celui qui a les droits d'administration ARD.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Anonyme
FiLH wrote:
Plusieurs solutions... ARD est la plus simple.
Appel Remode Display ? Pour des scripts ?
Apple Remote Desktop... En version 2.0 minimum...
Jouer avec l'encodage/décodage du mot de passe avec redirection des sortie en est une autre...
???
J'avais joué une fois avec l'envoi au moment de l'exécution du script du mot de passe chiffré dans un fichier et décodage de ce dit mot de passe avec renvoi sur l'entrée standard du résultat... J'étais fier de moi, mais c'était chiant à utiliser par rapport aux 2 autres solutions...
Tu peux aussi dire à sudo de ne pas demander de mot de passe pour une commande particulière, c'est encore une autre solution...
Je me suis fait mal comprendre : pour exécuter sur 90 clients une commandes à distance, sur une crontab par exemple.
Oui, et ?
Si tu dit à sudo que tel utilisateur n'aura pas à demander de mot de passe pour utiliser sudo sur la commande trucmuche, le dit utilisateur pourra utiliser cette commande "avec les droits" root. Cette commande peut-être un script ou autre...
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Jouer avec l'encodage/décodage du mot de passe avec redirection des
sortie en est une autre...
???
J'avais joué une fois avec l'envoi au moment de l'exécution du script du
mot de passe chiffré dans un fichier et décodage de ce dit mot de passe
avec renvoi sur l'entrée standard du résultat...
J'étais fier de moi, mais c'était chiant à utiliser par rapport aux 2
autres solutions...
Tu peux aussi dire à sudo de ne pas demander de mot de passe pour une
commande particulière, c'est encore une autre solution...
Je me suis fait mal comprendre : pour exécuter sur 90 clients une
commandes à distance, sur une crontab par exemple.
Oui, et ?
Si tu dit à sudo que tel utilisateur n'aura pas à demander de mot de
passe pour utiliser sudo sur la commande trucmuche, le dit utilisateur
pourra utiliser cette commande "avec les droits" root. Cette commande
peut-être un script ou autre...
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Jouer avec l'encodage/décodage du mot de passe avec redirection des sortie en est une autre...
???
J'avais joué une fois avec l'envoi au moment de l'exécution du script du mot de passe chiffré dans un fichier et décodage de ce dit mot de passe avec renvoi sur l'entrée standard du résultat... J'étais fier de moi, mais c'était chiant à utiliser par rapport aux 2 autres solutions...
Tu peux aussi dire à sudo de ne pas demander de mot de passe pour une commande particulière, c'est encore une autre solution...
Je me suis fait mal comprendre : pour exécuter sur 90 clients une commandes à distance, sur une crontab par exemple.
Oui, et ?
Si tu dit à sudo que tel utilisateur n'aura pas à demander de mot de passe pour utiliser sudo sur la commande trucmuche, le dit utilisateur pourra utiliser cette commande "avec les droits" root. Cette commande peut-être un script ou autre...
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Vu comme ça, 90% des utilisateurs (ceux du premier type) n'ont absolument aucun intérêt d'activer le compte root. Les autres peuvent trouver que ça un intérêt (je trouve qu'utiliser le compte root est plus simple que de créer un utilisateur admin)
Tu as de toute façons un compte admin (celui qui est crée à l'installation).
-- Jacques
Schmurtz <moi@ici.com> wrote:
Vu comme ça, 90% des utilisateurs (ceux du premier type) n'ont
absolument aucun intérêt d'activer le compte root. Les autres peuvent
trouver que ça un intérêt (je trouve qu'utiliser le compte root est plus
simple que de créer un utilisateur admin)
Tu as de toute façons un compte admin (celui qui est crée à
l'installation).
Vu comme ça, 90% des utilisateurs (ceux du premier type) n'ont absolument aucun intérêt d'activer le compte root. Les autres peuvent trouver que ça un intérêt (je trouve qu'utiliser le compte root est plus simple que de créer un utilisateur admin)
Tu as de toute façons un compte admin (celui qui est crée à l'installation).
-- Jacques
FiLH
(Anonyme) writes:
FiLH wrote:
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Heu si je peux me permettre root ne se distingue que pour ses droits. Donc utiliser les droits de root pour une tâche c'est équivalent à exécuter cette tâche sous root.
Maintenant ce qui me chiffone pas mal dans tout ce que tu as dit c'est que tu te fais bien chier pour pas grand choses sans aucune sécurité accrue.
En gros c'est de l'administration shadock : pourquoi faire simple quand on peut faire compliqué :)
Très valorisant intellectuellement par contre (ainsi que dans les réunions d'admins, très frime).
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
jayce@mosx.net (Anonyme) writes:
FiLH <filh@filh.org> wrote:
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Heu si je peux me permettre root ne se distingue que pour ses droits.
Donc utiliser les droits de root pour une tâche c'est équivalent à
exécuter cette tâche sous root.
Maintenant ce qui me chiffone pas mal dans tout ce que tu as dit c'est
que tu te fais bien chier pour pas grand choses sans aucune sécurité
accrue.
En gros c'est de l'administration shadock : pourquoi faire simple
quand on peut faire compliqué :)
Très valorisant intellectuellement par contre (ainsi que dans les
réunions d'admins, très frime).
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Heu si je peux me permettre root ne se distingue que pour ses droits. Donc utiliser les droits de root pour une tâche c'est équivalent à exécuter cette tâche sous root.
Maintenant ce qui me chiffone pas mal dans tout ce que tu as dit c'est que tu te fais bien chier pour pas grand choses sans aucune sécurité accrue.
En gros c'est de l'administration shadock : pourquoi faire simple quand on peut faire compliqué :)
Très valorisant intellectuellement par contre (ainsi que dans les réunions d'admins, très frime).
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Anonyme
FiLH wrote:
(Anonyme) writes:
FiLH wrote:
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Heu si je peux me permettre root ne se distingue que pour ses droits. Donc utiliser les droits de root pour une tâche c'est équivalent à exécuter cette tâche sous root.
Oui et non. Le fait qu'il n'y ait pas de compte root m'assure que seules les commandes voulues être lancées avec les droits root le sont.
Maintenant ce qui me chiffone pas mal dans tout ce que tu as dit c'est que tu te fais bien chier pour pas grand choses sans aucune sécurité accrue.
je ne me fais pas chier, au contraire, je n'ai pas eu à créer de comptes root, je n'ai pas eu à faire quoi que ce soit (à part la solution 2, mais c'était une branlette intellectuelle)...
En gros c'est de l'administration shadock : pourquoi faire simple quand on peut faire compliqué :)
Heu... Je vois pas ce qui est compliqué...
Très valorisant intellectuellement par contre (ainsi que dans les réunions d'admins, très frime).
La sécurité est accrue dans le sens que personne n'a le mot de passe root. Sudo est configuré pour certains comptes, ou certains groupes, et tout roule... La sécurité est accrue parce que je peux créer un compte qui n'aura, par exemple, que le droit de lancer softwareupdate...
Mais tout simplement, j'utilise maintenant ARD pour lancer mes scripts...
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Heu si je peux me permettre root ne se distingue que pour ses droits.
Donc utiliser les droits de root pour une tâche c'est équivalent à
exécuter cette tâche sous root.
Oui et non. Le fait qu'il n'y ait pas de compte root m'assure que seules
les commandes voulues être lancées avec les droits root le sont.
Maintenant ce qui me chiffone pas mal dans tout ce que tu as dit c'est
que tu te fais bien chier pour pas grand choses sans aucune sécurité
accrue.
je ne me fais pas chier, au contraire, je n'ai pas eu à créer de comptes
root, je n'ai pas eu à faire quoi que ce soit (à part la solution 2,
mais c'était une branlette intellectuelle)...
En gros c'est de l'administration shadock : pourquoi faire simple
quand on peut faire compliqué :)
Heu... Je vois pas ce qui est compliqué...
Très valorisant intellectuellement par contre (ainsi que dans les
réunions d'admins, très frime).
La sécurité est accrue dans le sens que personne n'a le mot de passe
root. Sudo est configuré pour certains comptes, ou certains groupes, et
tout roule...
La sécurité est accrue parce que je peux créer un compte qui n'aura, par
exemple, que le droit de lancer softwareupdate...
Mais tout simplement, j'utilise maintenant ARD pour lancer mes
scripts...
En fait cela revient de toutes façons à utiliser root.
Non, mais à utiliser les droits de root pour une tâche particulière...
Heu si je peux me permettre root ne se distingue que pour ses droits. Donc utiliser les droits de root pour une tâche c'est équivalent à exécuter cette tâche sous root.
Oui et non. Le fait qu'il n'y ait pas de compte root m'assure que seules les commandes voulues être lancées avec les droits root le sont.
Maintenant ce qui me chiffone pas mal dans tout ce que tu as dit c'est que tu te fais bien chier pour pas grand choses sans aucune sécurité accrue.
je ne me fais pas chier, au contraire, je n'ai pas eu à créer de comptes root, je n'ai pas eu à faire quoi que ce soit (à part la solution 2, mais c'était une branlette intellectuelle)...
En gros c'est de l'administration shadock : pourquoi faire simple quand on peut faire compliqué :)
Heu... Je vois pas ce qui est compliqué...
Très valorisant intellectuellement par contre (ainsi que dans les réunions d'admins, très frime).
La sécurité est accrue dans le sens que personne n'a le mot de passe root. Sudo est configuré pour certains comptes, ou certains groupes, et tout roule... La sécurité est accrue parce que je peux créer un compte qui n'aura, par exemple, que le droit de lancer softwareupdate...
Mais tout simplement, j'utilise maintenant ARD pour lancer mes scripts...
La sécurité est accrue dans le sens que personne n'a le mot de passe root.
Comme le fait d'avoir un mot de passe admin est strictement équivalent à avoir un mot de passe root, je ne vois pas ce que ça change en terme de sécurité.
À un moment donné il y a bien un admin qui a tout pouvoir sur la machine.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
jayce@mosx.net (Anonyme) writes:
FiLH <filh@filh.org> wrote:
La sécurité est accrue dans le sens que personne n'a le mot de passe
root.
Comme le fait d'avoir un mot de passe admin est strictement équivalent
à avoir un mot de passe root, je ne vois pas ce que ça change en terme
de sécurité.
À un moment donné il y a bien un admin qui a tout pouvoir sur la machine.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
La sécurité est accrue dans le sens que personne n'a le mot de passe root.
Comme le fait d'avoir un mot de passe admin est strictement équivalent à avoir un mot de passe root, je ne vois pas ce que ça change en terme de sécurité.
À un moment donné il y a bien un admin qui a tout pouvoir sur la machine.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Anonyme
FiLH wrote:
(Anonyme) writes:
FiLH wrote:
La sécurité est accrue dans le sens que personne n'a le mot de passe root.
Comme le fait d'avoir un mot de passe admin est strictement équivalent à avoir un mot de passe root, je ne vois pas ce que ça change en terme de sécurité.
Ca n'a rien à voir...
À un moment donné il y a bien un admin qui a tout pouvoir sur la machine.
Oui, à un moment, mais là n'est pas le problème. Quand un admin est admin, il est normal qu'il ait les droits d'admin tant qu'il est admin. Le problème se pose lorsque l'admin ne doit plus être admin, et il peut y avoir différentes raisons à cela. Si l'admin a les mots de passe root, cela t'oblige à changer tous les mots de passe root, alors que si il a un compte admin, tu peux soit désactiver son compte ou le sortir du groupe admin.
De plus, comme je l'ai déjà dit, tu peux aussi faire des demi-admins, qui n'ont le droit de faire que certaines choses... Et ceux là n'ont pas tous les droits...
La sécurité est accrue dans le sens que personne n'a le mot de passe
root.
Comme le fait d'avoir un mot de passe admin est strictement équivalent
à avoir un mot de passe root, je ne vois pas ce que ça change en terme
de sécurité.
Ca n'a rien à voir...
À un moment donné il y a bien un admin qui a tout pouvoir sur la machine.
Oui, à un moment, mais là n'est pas le problème. Quand un admin est
admin, il est normal qu'il ait les droits d'admin tant qu'il est admin.
Le problème se pose lorsque l'admin ne doit plus être admin, et il peut
y avoir différentes raisons à cela. Si l'admin a les mots de passe root,
cela t'oblige à changer tous les mots de passe root, alors que si il a
un compte admin, tu peux soit désactiver son compte ou le sortir du
groupe admin.
De plus, comme je l'ai déjà dit, tu peux aussi faire des demi-admins,
qui n'ont le droit de faire que certaines choses... Et ceux là n'ont pas
tous les droits...
La sécurité est accrue dans le sens que personne n'a le mot de passe root.
Comme le fait d'avoir un mot de passe admin est strictement équivalent à avoir un mot de passe root, je ne vois pas ce que ça change en terme de sécurité.
Ca n'a rien à voir...
À un moment donné il y a bien un admin qui a tout pouvoir sur la machine.
Oui, à un moment, mais là n'est pas le problème. Quand un admin est admin, il est normal qu'il ait les droits d'admin tant qu'il est admin. Le problème se pose lorsque l'admin ne doit plus être admin, et il peut y avoir différentes raisons à cela. Si l'admin a les mots de passe root, cela t'oblige à changer tous les mots de passe root, alors que si il a un compte admin, tu peux soit désactiver son compte ou le sortir du groupe admin.
De plus, comme je l'ai déjà dit, tu peux aussi faire des demi-admins, qui n'ont le droit de faire que certaines choses... Et ceux là n'ont pas tous les droits...
À (at) 20 Oct 2004 12:04:04 +0200, FiLH écrivait (wrote):
Comme le fait d'avoir un mot de passe admin est strictement équivalent à avoir un mot de passe root, je ne vois pas ce que ça change en terme de sécurité.
Le non partage de mot de passe est l'une des bases de la sécurité.
Le jour où l'un des administrateurs quitte la structure, il suffit de désactiver son compte. On n'a pas a changé tous les mots de passe 'root'.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) 20 Oct 2004 12:04:04 +0200,
FiLH <filh@filh.org> écrivait (wrote):
Comme le fait d'avoir un mot de passe admin est strictement équivalent
à avoir un mot de passe root, je ne vois pas ce que ça change en terme
de sécurité.
Le non partage de mot de passe est l'une des bases de la sécurité.
Le jour où l'un des administrateurs quitte la structure, il suffit de
désactiver son compte. On n'a pas a changé tous les mots de passe 'root'.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) 20 Oct 2004 12:04:04 +0200, FiLH écrivait (wrote):
Comme le fait d'avoir un mot de passe admin est strictement équivalent à avoir un mot de passe root, je ne vois pas ce que ça change en terme de sécurité.
Le non partage de mot de passe est l'une des bases de la sécurité.
Le jour où l'un des administrateurs quitte la structure, il suffit de désactiver son compte. On n'a pas a changé tous les mots de passe 'root'.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
