Bonjour =E0 tous,
Comment faire pour qu'un utilisateur ne puisse pas remonter dans
l'abroressence, qu'il soit limit=E9 =E0 son r=E9pertoire ?
J'ai essay=E9 rbash mais c pas fiable : il lui suffit de faire vim
/root/n'importe quel fichier=20
et ca fonctionne.
Ce répertoire est destiné à l'administrateur de la machine dans lequel il y stocke généralement ses outils, des fichiers de configuration et son profile qui, s'ils sont lus, peuvent révéler des informations cruciales mettant alors en danger la sécurité du système et de la machine.
Moi, j'ai une autre version.
Ce répertoire ne sert à rien. Les outils, fichiers de configuration n'ont pas besoin de super-privilèges sauf au moment précis ou on les installe. Donc si on est parano, on les met sur un compte non-root dédié à l'administration, et on paranoifie le compte en conséquents.
M'enfin ceci dit, j'ai jamais administré de système compliqués.
Par exemple, il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement.
(chez moi, y'a autant dire rien dans /root)
$ vi /root/.bash_history
"/root/.bash_history" [Permission Denied] 0,0-1 All
Ouf, mon système est plus intelligent que moi ;-).
(mais ceci dit, c'est aussi une très bonne raison de ne jamais tapper de mot de passe sur une ligne de commande)
(et tout ceci étant dit, même si je ne pense pas que le "chmod 700 /root" soit strictement nécessaire, il ne fait pas de mal non plus)
-- Matthieu
"TiChou" <gro.uohcit@uohcit> writes:
Ce répertoire est destiné à l'administrateur de la machine dans lequel
il y stocke généralement ses outils, des fichiers de configuration et
son profile qui, s'ils sont lus, peuvent révéler des informations
cruciales mettant alors en danger la sécurité du système et de la
machine.
Moi, j'ai une autre version.
Ce répertoire ne sert à rien. Les outils, fichiers de configuration
n'ont pas besoin de super-privilèges sauf au moment précis ou on les
installe. Donc si on est parano, on les met sur un compte non-root
dédié à l'administration, et on paranoifie le compte en conséquents.
M'enfin ceci dit, j'ai jamais administré de système compliqués.
Par exemple, il n'est pas rare, sur certaines machines, de retrouver
dans le fichier historique du shell des mots de passe saisis
maladroitement.
(chez moi, y'a autant dire rien dans /root)
$ vi /root/.bash_history
"/root/.bash_history" [Permission Denied] 0,0-1 All
Ouf, mon système est plus intelligent que moi ;-).
(mais ceci dit, c'est aussi une très bonne raison de ne jamais tapper
de mot de passe sur une ligne de commande)
(et tout ceci étant dit, même si je ne pense pas que le "chmod 700
/root" soit strictement nécessaire, il ne fait pas de mal non plus)
Ce répertoire est destiné à l'administrateur de la machine dans lequel il y stocke généralement ses outils, des fichiers de configuration et son profile qui, s'ils sont lus, peuvent révéler des informations cruciales mettant alors en danger la sécurité du système et de la machine.
Moi, j'ai une autre version.
Ce répertoire ne sert à rien. Les outils, fichiers de configuration n'ont pas besoin de super-privilèges sauf au moment précis ou on les installe. Donc si on est parano, on les met sur un compte non-root dédié à l'administration, et on paranoifie le compte en conséquents.
M'enfin ceci dit, j'ai jamais administré de système compliqués.
Par exemple, il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement.
(chez moi, y'a autant dire rien dans /root)
$ vi /root/.bash_history
"/root/.bash_history" [Permission Denied] 0,0-1 All
Ouf, mon système est plus intelligent que moi ;-).
(mais ceci dit, c'est aussi une très bonne raison de ne jamais tapper de mot de passe sur une ligne de commande)
(et tout ceci étant dit, même si je ne pense pas que le "chmod 700 /root" soit strictement nécessaire, il ne fait pas de mal non plus)
-- Matthieu
TiChou
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
[/root]
Moi, j'ai une autre version.
Ce répertoire ne sert à rien.
Parce que vous n'en avez pas l'utilité ou n'en avez pas (encore) saisis son utilité.
Les outils, fichiers de configuration n'ont pas besoin de super- privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Donc si on est parano, on les met sur un compte non-root dédié à l'administration, et on paranoifie le compte en conséquents.
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès alors qu'il suffit tout simplement de protéger /root ? J'avoue n'avoir pas très bien compris le raisonnement. En gros, je ne protège pas /root, mais tout ce qui est important de protéger pour l'administrateur seul je le mets sur un autre compte ?
Par exemple, il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement. [...]
(mais ceci dit, c'est aussi une très bonne raison de ne jamais tapper de mot de passe sur une ligne de commande)
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par exemple avant l'affichage de l'invite 'password:' ?
-- TiChou
Dans le message <news:vpq8xv7owsu.fsf@ecrins.imag.fr>,
*Matthieu Moy* tapota sur f.c.o.l.configuration :
[/root]
Moi, j'ai une autre version.
Ce répertoire ne sert à rien.
Parce que vous n'en avez pas l'utilité ou n'en avez pas (encore) saisis son
utilité.
Les outils, fichiers de configuration n'ont pas besoin de super-
privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par
mot de passe pour accéder aux données à archiver. Et bien pour un tel
script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Donc si on est parano, on les met sur un compte non-root
dédié à l'administration, et on paranoifie le compte en conséquents.
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès
alors qu'il suffit tout simplement de protéger /root ?
J'avoue n'avoir pas très bien compris le raisonnement. En gros, je ne
protège pas /root, mais tout ce qui est important de protéger pour
l'administrateur seul je le mets sur un autre compte ?
Par exemple, il n'est pas rare, sur certaines machines, de retrouver
dans le fichier historique du shell des mots de passe saisis
maladroitement.
[...]
(mais ceci dit, c'est aussi une très bonne raison de ne jamais tapper
de mot de passe sur une ligne de commande)
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par
exemple avant l'affichage de l'invite 'password:' ?
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
[/root]
Moi, j'ai une autre version.
Ce répertoire ne sert à rien.
Parce que vous n'en avez pas l'utilité ou n'en avez pas (encore) saisis son utilité.
Les outils, fichiers de configuration n'ont pas besoin de super- privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Donc si on est parano, on les met sur un compte non-root dédié à l'administration, et on paranoifie le compte en conséquents.
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès alors qu'il suffit tout simplement de protéger /root ? J'avoue n'avoir pas très bien compris le raisonnement. En gros, je ne protège pas /root, mais tout ce qui est important de protéger pour l'administrateur seul je le mets sur un autre compte ?
Par exemple, il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement. [...]
(mais ceci dit, c'est aussi une très bonne raison de ne jamais tapper de mot de passe sur une ligne de commande)
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par exemple avant l'affichage de l'invite 'password:' ?
-- TiChou
TiChou
Dans le message <news:dminsj$19ij$, *Luc Habert* tapota sur f.c.o.l.configuration :
il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement.
[...] Et puis c'est valable tout autant pour les simples utilisateurs,
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
est-ce qu'il faut pour autant mettre leur home en parano?
Les mettre par défaut à 711 me semblent être la moindre des choses, mais après cela regarde chaque utilisateur.
-- TiChou
Dans le message <news:dminsj$19ij$1@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
il n'est pas rare, sur certaines machines, de retrouver dans
le fichier historique du shell des mots de passe saisis maladroitement.
[...] Et puis c'est valable tout autant pour les simples utilisateurs,
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant
d'importance que celui de l'administrateur ?
est-ce qu'il faut pour autant mettre leur home en parano?
Les mettre par défaut à 711 me semblent être la moindre des choses, mais
après cela regarde chaque utilisateur.
Dans le message <news:dminsj$19ij$, *Luc Habert* tapota sur f.c.o.l.configuration :
il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement.
[...] Et puis c'est valable tout autant pour les simples utilisateurs,
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
est-ce qu'il faut pour autant mettre leur home en parano?
Les mettre par défaut à 711 me semblent être la moindre des choses, mais après cela regarde chaque utilisateur.
-- TiChou
Matthieu Moy
"TiChou" writes:
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
Les outils, fichiers de configuration n'ont pas besoin de super- privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu préfères donc être root à chaques fois que tu dois accéder à ce fichier. Moi, je préfère avoir un utilisateur simple pour écrire mes scripts, et root seulement pour les executer. Si il y a un mot de passe quelque part, il ne doit pas être dans le script lui-même (regarder par exemple http://koders.com/?s=mysql_connect pour se convaincre de l'intérêt de séparer le code et les mots de passe).
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès alors qu'il suffit tout simplement de protéger /root ?
Si tu protège /root et que tu met pleins de choses dedans, tu t'obliges à passer root plus souvent.
Typiquement, compiler un logiciel avant de l'installer, pleins de gens le font dans /root, mais je trouve que c'est une connerie plus qu'autre chose.
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par exemple avant l'affichage de l'invite 'password:' ?
Meuh non, voyons (sauf des fois ;-).
-- Matthieu
"TiChou" <gro.uohcit@uohcit> writes:
Dans le message <news:vpq8xv7owsu.fsf@ecrins.imag.fr>,
*Matthieu Moy* tapota sur f.c.o.l.configuration :
Les outils, fichiers de configuration n'ont pas besoin de super-
privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord
s'authentifier par mot de passe pour accéder aux données à archiver.
Et bien pour un tel script, je préfère qu'il ne soit accessible que
dans /root et pas ailleurs.
Tu préfères donc être root à chaques fois que tu dois accéder à ce
fichier. Moi, je préfère avoir un utilisateur simple pour écrire mes
scripts, et root seulement pour les executer. Si il y a un mot de
passe quelque part, il ne doit pas être dans le script lui-même
(regarder par exemple http://koders.com/?s=mysql_connect pour se
convaincre de l'intérêt de séparer le code et les mots de passe).
Quel avantage d'avoir un autre compte, qui de plus serait blindé à
l'accès alors qu'il suffit tout simplement de protéger /root ?
Si tu protège /root et que tu met pleins de choses dedans, tu
t'obliges à passer root plus souvent.
Typiquement, compiler un logiciel avant de l'installer, pleins de gens
le font dans /root, mais je trouve que c'est une connerie plus
qu'autre chose.
Cela ne vous ai jamais arrivé de saisir un mot de passe trop
rapidement, par exemple avant l'affichage de l'invite 'password:' ?
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
Les outils, fichiers de configuration n'ont pas besoin de super- privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu préfères donc être root à chaques fois que tu dois accéder à ce fichier. Moi, je préfère avoir un utilisateur simple pour écrire mes scripts, et root seulement pour les executer. Si il y a un mot de passe quelque part, il ne doit pas être dans le script lui-même (regarder par exemple http://koders.com/?s=mysql_connect pour se convaincre de l'intérêt de séparer le code et les mots de passe).
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès alors qu'il suffit tout simplement de protéger /root ?
Si tu protège /root et que tu met pleins de choses dedans, tu t'obliges à passer root plus souvent.
Typiquement, compiler un logiciel avant de l'installer, pleins de gens le font dans /root, mais je trouve que c'est une connerie plus qu'autre chose.
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par exemple avant l'affichage de l'invite 'password:' ?
Meuh non, voyons (sauf des fois ;-).
-- Matthieu
Matthieu Moy
"TiChou" writes:
Dans le message <news:dminsj$19ij$, *Luc Habert* tapota sur f.c.o.l.configuration :
il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement.
[...] Et puis c'est valable tout autant pour les simples utilisateurs,
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Un utilisateur simple peut utiliser son navigateur pour aller sur le site de sa banque, par exemple. Son mot de passe local est "moins important", mais ça ne veut pas dire que l'ensemble des données qui sont sur son compte sont moins importantes.
-- Matthieu
"TiChou" <gro.uohcit@uohcit> writes:
Dans le message <news:dminsj$19ij$1@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
il n'est pas rare, sur certaines machines, de retrouver dans
le fichier historique du shell des mots de passe saisis maladroitement.
[...] Et puis c'est valable tout autant pour les simples utilisateurs,
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant
d'importance que celui de l'administrateur ?
Un utilisateur simple peut utiliser son navigateur pour aller sur le
site de sa banque, par exemple. Son mot de passe local est "moins
important", mais ça ne veut pas dire que l'ensemble des données qui
sont sur son compte sont moins importantes.
Dans le message <news:dminsj$19ij$, *Luc Habert* tapota sur f.c.o.l.configuration :
il n'est pas rare, sur certaines machines, de retrouver dans le fichier historique du shell des mots de passe saisis maladroitement.
[...] Et puis c'est valable tout autant pour les simples utilisateurs,
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Un utilisateur simple peut utiliser son navigateur pour aller sur le site de sa banque, par exemple. Son mot de passe local est "moins important", mais ça ne veut pas dire que l'ensemble des données qui sont sur son compte sont moins importantes.
-- Matthieu
lhabert
"TiChou" :
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Il est assez rare pour root de devoir taper son propre mot de passe... En fait, c'est plus chez les simples utilisateurs que ça risque d'arriver, ça...
Les mettre par défaut à 711 me semblent être la moindre des choses, mais après cela regarde chaque utilisateur.
Mais halte à la paranoia! On protège explicitement tout ce qu'on veut protéger, et on laisse le reste en accès libre et visible, sinon ça ne sert pas à grand chose (entre envoyer le fichier par mail et envoyer son chemin d'accès, c'est tout aussi peu pratique).
"TiChou" :
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant
d'importance que celui de l'administrateur ?
Il est assez rare pour root de devoir taper son propre mot de passe... En
fait, c'est plus chez les simples utilisateurs que ça risque d'arriver,
ça...
Les mettre par défaut à 711 me semblent être la moindre des choses, mais
après cela regarde chaque utilisateur.
Mais halte à la paranoia! On protège explicitement tout ce qu'on veut
protéger, et on laisse le reste en accès libre et visible, sinon ça ne sert
pas à grand chose (entre envoyer le fichier par mail et envoyer son chemin
d'accès, c'est tout aussi peu pratique).
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Il est assez rare pour root de devoir taper son propre mot de passe... En fait, c'est plus chez les simples utilisateurs que ça risque d'arriver, ça...
Les mettre par défaut à 711 me semblent être la moindre des choses, mais après cela regarde chaque utilisateur.
Mais halte à la paranoia! On protège explicitement tout ce qu'on veut protéger, et on laisse le reste en accès libre et visible, sinon ça ne sert pas à grand chose (entre envoyer le fichier par mail et envoyer son chemin d'accès, c'est tout aussi peu pratique).
Nicolas George
"TiChou" wrote in message :
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Depuis sudo ?
"TiChou" wrote in message <polom.20051130005919@florizarre.tichou.org>:
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant
d'importance que celui de l'administrateur ?
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Depuis sudo ?
Nicolas George
"TiChou" wrote in message :
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu mets des mots de passe en clair dans des scripts, toi ?
"TiChou" wrote in message <pwet.20051130003445@florizarre.tichou.org>:
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par
mot de passe pour accéder aux données à archiver. Et bien pour un tel
script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu mets des mots de passe en clair dans des scripts, toi ?
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu mets des mots de passe en clair dans des scripts, toi ?
TiChou
Dans le message <news:dmiqo1$1qik$, *Luc Habert* tapota sur f.c.o.l.configuration :
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Il est assez rare pour root de devoir taper son propre mot de passe... En fait, c'est plus chez les simples utilisateurs que ça risque d'arriver, ça...
Je viens de me rendre compte qu'on n'était pas sur la même longueur d'onde. Je ne parlais pas nécessairement des mots de passe des comptes unix mais plutôt des mots de passe saisis par l'administrateur pour accéder aux différentes ressources locales.
Les mettre par défaut à 711 me semblent être la moindre des choses, mais après cela regarde chaque utilisateur.
Mais halte à la paranoia!
Halte au laxisme !
On protège explicitement tout ce qu'on veut protéger, et on laisse le reste en accès libre et visible, sinon ça ne sert pas à grand chose
Je crois rêver.
-- TiChou
Dans le message <news:dmiqo1$1qik$1@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant
d'importance que celui de l'administrateur ?
Il est assez rare pour root de devoir taper son propre mot de passe... En
fait, c'est plus chez les simples utilisateurs que ça risque d'arriver,
ça...
Je viens de me rendre compte qu'on n'était pas sur la même longueur d'onde.
Je ne parlais pas nécessairement des mots de passe des comptes unix mais
plutôt des mots de passe saisis par l'administrateur pour accéder aux
différentes ressources locales.
Les mettre par défaut à 711 me semblent être la moindre des choses, mais
après cela regarde chaque utilisateur.
Mais halte à la paranoia!
Halte au laxisme !
On protège explicitement tout ce qu'on veut protéger, et on laisse le
reste en accès libre et visible, sinon ça ne sert pas à grand chose
Dans le message <news:dmiqo1$1qik$, *Luc Habert* tapota sur f.c.o.l.configuration :
Ah, et depuis quand le mot de passe d'un simple utilisateur a autant d'importance que celui de l'administrateur ?
Il est assez rare pour root de devoir taper son propre mot de passe... En fait, c'est plus chez les simples utilisateurs que ça risque d'arriver, ça...
Je viens de me rendre compte qu'on n'était pas sur la même longueur d'onde. Je ne parlais pas nécessairement des mots de passe des comptes unix mais plutôt des mots de passe saisis par l'administrateur pour accéder aux différentes ressources locales.
Les mettre par défaut à 711 me semblent être la moindre des choses, mais après cela regarde chaque utilisateur.
Mais halte à la paranoia!
Halte au laxisme !
On protège explicitement tout ce qu'on veut protéger, et on laisse le reste en accès libre et visible, sinon ça ne sert pas à grand chose
Je crois rêver.
-- TiChou
TiChou
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
Les outils, fichiers de configuration n'ont pas besoin de super- privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu préfères donc être root à chaques fois que tu dois accéder à ce fichier.
À chaque fois que l'administrateur doit lancer le script.
Moi, je préfère avoir un utilisateur simple pour écrire mes scripts, et root seulement pour les executer.
Ça multiplie donc par deux les possibilités d'accéder aux fichiers. Soit par l'utilisateur en question soit par root.
Si il y a un mot de passe quelque part, il ne doit pas être dans le script lui-même
Ça ne change rien au problème. Ce qui importe c'est que l'accès au mot de passe ne soit possible que par root.
(regarder par exemple http://koders.com/?s=mysql_connect pour se convaincre de l'intérêt de séparer le code et les mots de passe).
Mauvais exemple. Ici l'intérêt de séparer les mots de passe du code est de séparer ce qui est directement accessible par la ressource de ce qui est autorisé au client à être accessible par la ressource.
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès alors qu'il suffit tout simplement de protéger /root ?
Si tu protège /root et que tu met pleins de choses dedans,
Non, pas pleins de choses, juste les choses nécessaires à l'administrateur et uniquement à lui.
tu t'obliges à passer root plus souvent.
Non car il s'agit ici de lancer des outils uniquement en tant que root.
Typiquement, compiler un logiciel avant de l'installer, pleins de gens le font dans /root, mais je trouve que c'est une connerie plus qu'autre chose.
Entièrement d'accord et je précise que je n'ai jamais sous entendu ou recommandé ce type d'utilisation dans /root que ça soit dans mes précédents messages ou dans le passé (voir archives).
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par exemple avant l'affichage de l'invite 'password:' ?
Meuh non, voyons (sauf des fois ;-).
Il suffit d'une fois.
-- TiChou
Dans le message <news:vpq4q5vov4n.fsf@ecrins.imag.fr>,
*Matthieu Moy* tapota sur f.c.o.l.configuration :
Les outils, fichiers de configuration n'ont pas besoin de super-
privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord
s'authentifier par mot de passe pour accéder aux données à archiver.
Et bien pour un tel script, je préfère qu'il ne soit accessible que
dans /root et pas ailleurs.
Tu préfères donc être root à chaques fois que tu dois accéder à ce
fichier.
À chaque fois que l'administrateur doit lancer le script.
Moi, je préfère avoir un utilisateur simple pour écrire mes
scripts, et root seulement pour les executer.
Ça multiplie donc par deux les possibilités d'accéder aux fichiers. Soit par
l'utilisateur en question soit par root.
Si il y a un mot de passe quelque part, il ne doit pas être dans le
script lui-même
Ça ne change rien au problème. Ce qui importe c'est que l'accès au mot de
passe ne soit possible que par root.
(regarder par exemple http://koders.com/?s=mysql_connect pour se
convaincre de l'intérêt de séparer le code et les mots de passe).
Mauvais exemple. Ici l'intérêt de séparer les mots de passe du code est de
séparer ce qui est directement accessible par la ressource de ce qui est
autorisé au client à être accessible par la ressource.
Quel avantage d'avoir un autre compte, qui de plus serait blindé à
l'accès alors qu'il suffit tout simplement de protéger /root ?
Si tu protège /root et que tu met pleins de choses dedans,
Non, pas pleins de choses, juste les choses nécessaires à l'administrateur
et uniquement à lui.
tu t'obliges à passer root plus souvent.
Non car il s'agit ici de lancer des outils uniquement en tant que root.
Typiquement, compiler un logiciel avant de l'installer, pleins de gens
le font dans /root, mais je trouve que c'est une connerie plus
qu'autre chose.
Entièrement d'accord et je précise que je n'ai jamais sous entendu ou
recommandé ce type d'utilisation dans /root que ça soit dans mes précédents
messages ou dans le passé (voir archives).
Cela ne vous ai jamais arrivé de saisir un mot de passe trop
rapidement, par exemple avant l'affichage de l'invite 'password:' ?
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
Les outils, fichiers de configuration n'ont pas besoin de super- privilèges sauf au moment précis ou on les installe.
Prenons l'exemple d'un script d'archivage devant d'abord s'authentifier par mot de passe pour accéder aux données à archiver. Et bien pour un tel script, je préfère qu'il ne soit accessible que dans /root et pas ailleurs.
Tu préfères donc être root à chaques fois que tu dois accéder à ce fichier.
À chaque fois que l'administrateur doit lancer le script.
Moi, je préfère avoir un utilisateur simple pour écrire mes scripts, et root seulement pour les executer.
Ça multiplie donc par deux les possibilités d'accéder aux fichiers. Soit par l'utilisateur en question soit par root.
Si il y a un mot de passe quelque part, il ne doit pas être dans le script lui-même
Ça ne change rien au problème. Ce qui importe c'est que l'accès au mot de passe ne soit possible que par root.
(regarder par exemple http://koders.com/?s=mysql_connect pour se convaincre de l'intérêt de séparer le code et les mots de passe).
Mauvais exemple. Ici l'intérêt de séparer les mots de passe du code est de séparer ce qui est directement accessible par la ressource de ce qui est autorisé au client à être accessible par la ressource.
Quel avantage d'avoir un autre compte, qui de plus serait blindé à l'accès alors qu'il suffit tout simplement de protéger /root ?
Si tu protège /root et que tu met pleins de choses dedans,
Non, pas pleins de choses, juste les choses nécessaires à l'administrateur et uniquement à lui.
tu t'obliges à passer root plus souvent.
Non car il s'agit ici de lancer des outils uniquement en tant que root.
Typiquement, compiler un logiciel avant de l'installer, pleins de gens le font dans /root, mais je trouve que c'est une connerie plus qu'autre chose.
Entièrement d'accord et je précise que je n'ai jamais sous entendu ou recommandé ce type d'utilisation dans /root que ça soit dans mes précédents messages ou dans le passé (voir archives).
Cela ne vous ai jamais arrivé de saisir un mot de passe trop rapidement, par exemple avant l'affichage de l'invite 'password:' ?
