Il m'arrive assez souvent d'avoir à faire des trucs bénins sur un
système, et j'aimerais pouvoir le faire sans passer root (avec tous
les risques que ça comporte en cas d'erreur).
Par exemple, je voudrais faire un "passwd -S machin". C'est pas
méchant, ça ne modifie rien dans le système.
Mais si je passe root (su, sudo), et que je fais une erreur dans la
commande, les conséquences peuvent être fâcheuses.
De même, j'aimerais pouvoir faire un fdisk /dev/hda, et avoir accès à
tout sauf la commande "w" -- en d'autres termes, pouvoir regarder et
expérimenter tout mon saoûl, mais ne rien pouvoir écrire réellement
sur le disque.
Une solution serait d'avoir une machine "miroir", exactement identique
en tout point, sur laquelle je pourrais faire tout ce que je veux sans
risquer de casser la machine principale, mais bon... c'est un peu
lourd quand il s'agit juste de vérifier qu'un compte n'a pas de mot de
passe.
rootkit et alors le backup (sauf /home) ne sert à pas grand chose....
Tout dépends du backup. Et tout dépends de la façon dont la machine est utilisée, de l'importance de la machine et du cout qu'entrainerait une panne.
Sur un serveur qui ne change pas de config, perso je le clones après chaque grosse modif puis ne sauvegardes que les data.
Sur une machine en perpetuel changement, évidement, c'est plus dur mais conserver un full du système chaque semaine sur 3 mois puis un full mensuel sur un an devrait déjà aider.
Bien documenter chaque modif est aussi une très bonne chose pour pouvoir ensuite remonter rapidement la config à l'identique en cas de grosse cata.
Et bien évidement, pour toute manip sortant de l'ordinaire, un serveur de test est nécessaire amha.
Après, pour répondre à Fabien, tu peux effectivement envisager quelques solutions de sécurisation, comme de monter la partition système en read only, sceller le système avec lids, ... J'ai pas testé cependant.
Mais à mon sens ajouter une couche de complexité au système n'est pas un très bon paliatif à une erreur de manip, puisque cette couche de complexité augmente d'autant les risques de fausses manip. -- Nicolas
Yves Lambert <leiota@invalid.bidart.net> wrote:
rootkit et alors le backup (sauf /home) ne sert à pas grand chose....
Tout dépends du backup.
Et tout dépends de la façon dont la machine est utilisée,
de l'importance de la machine et du cout qu'entrainerait une panne.
Sur un serveur qui ne change pas de config, perso je le clones après
chaque grosse modif puis ne sauvegardes que les data.
Sur une machine en perpetuel changement, évidement, c'est plus dur mais
conserver un full du système chaque semaine sur 3 mois puis un full
mensuel sur un an devrait déjà aider.
Bien documenter chaque modif est aussi une très bonne chose pour pouvoir
ensuite remonter rapidement la config à l'identique en cas de grosse
cata.
Et bien évidement, pour toute manip sortant de l'ordinaire, un serveur
de test est nécessaire amha.
Après, pour répondre à Fabien, tu peux effectivement envisager quelques
solutions de sécurisation, comme de monter la partition système en read
only, sceller le système avec lids, ...
J'ai pas testé cependant.
Mais à mon sens ajouter une couche de complexité au système n'est pas un
très bon paliatif à une erreur de manip, puisque cette couche de
complexité augmente d'autant les risques de fausses manip.
--
Nicolas
rootkit et alors le backup (sauf /home) ne sert à pas grand chose....
Tout dépends du backup. Et tout dépends de la façon dont la machine est utilisée, de l'importance de la machine et du cout qu'entrainerait une panne.
Sur un serveur qui ne change pas de config, perso je le clones après chaque grosse modif puis ne sauvegardes que les data.
Sur une machine en perpetuel changement, évidement, c'est plus dur mais conserver un full du système chaque semaine sur 3 mois puis un full mensuel sur un an devrait déjà aider.
Bien documenter chaque modif est aussi une très bonne chose pour pouvoir ensuite remonter rapidement la config à l'identique en cas de grosse cata.
Et bien évidement, pour toute manip sortant de l'ordinaire, un serveur de test est nécessaire amha.
Après, pour répondre à Fabien, tu peux effectivement envisager quelques solutions de sécurisation, comme de monter la partition système en read only, sceller le système avec lids, ... J'ai pas testé cependant.
Mais à mon sens ajouter une couche de complexité au système n'est pas un très bon paliatif à une erreur de manip, puisque cette couche de complexité augmente d'autant les risques de fausses manip. -- Nicolas
Fabien LE LEZ
Après, pour répondre à Fabien, tu peux effectivement envisager quelques solutions de sécurisation, comme de monter la partition système en read only, sceller le système avec lids, ...
Note que je demande l'inverse : réduire la sécurité du système, en autorisant un utilisateur non-root bien précis, à faire certaines choses normalement réservées à root.
Root, quant à lui, continue à avoir tous les pouvoirs.
Après, pour répondre à Fabien, tu peux effectivement envisager quelques
solutions de sécurisation, comme de monter la partition système en read
only, sceller le système avec lids, ...
Note que je demande l'inverse : réduire la sécurité du système, en
autorisant un utilisateur non-root bien précis, à faire certaines
choses normalement réservées à root.
Root, quant à lui, continue à avoir tous les pouvoirs.
Après, pour répondre à Fabien, tu peux effectivement envisager quelques solutions de sécurisation, comme de monter la partition système en read only, sceller le système avec lids, ...
Note que je demande l'inverse : réduire la sécurité du système, en autorisant un utilisateur non-root bien précis, à faire certaines choses normalement réservées à root.
Root, quant à lui, continue à avoir tous les pouvoirs.
Nicolas.MICHEL
Fabien LE LEZ wrote:
Après, pour répondre à Fabien, tu peux effectivement envisager quelques solutions de sécurisation, comme de monter la partition système en read only, sceller le système avec lids, ...
Note que je demande l'inverse : réduire la sécurité du système, en autorisant un utilisateur non-root bien précis, à faire certaines choses normalement réservées à root.
Root, quant à lui, continue à avoir tous les pouvoirs.
Le problème est que le système n'est pas vraiment conçu comme ça.
Tu pourrais par contre utiliser les ACL pour que toto ai le droit en lecture sur tout ton disque.
-- Nicolas
Fabien LE LEZ <gramster@gramster.com> wrote:
Après, pour répondre à Fabien, tu peux effectivement envisager quelques
solutions de sécurisation, comme de monter la partition système en read
only, sceller le système avec lids, ...
Note que je demande l'inverse : réduire la sécurité du système, en
autorisant un utilisateur non-root bien précis, à faire certaines
choses normalement réservées à root.
Root, quant à lui, continue à avoir tous les pouvoirs.
Le problème est que le système n'est pas vraiment conçu comme ça.
Tu pourrais par contre utiliser les ACL pour que toto ai le droit en
lecture sur tout ton disque.
Après, pour répondre à Fabien, tu peux effectivement envisager quelques solutions de sécurisation, comme de monter la partition système en read only, sceller le système avec lids, ...
Note que je demande l'inverse : réduire la sécurité du système, en autorisant un utilisateur non-root bien précis, à faire certaines choses normalement réservées à root.
Root, quant à lui, continue à avoir tous les pouvoirs.
Le problème est que le système n'est pas vraiment conçu comme ça.
Tu pourrais par contre utiliser les ACL pour que toto ai le droit en lecture sur tout ton disque.
