Vous n'êtes pas identifié(e).
à chaque fois que je modifie un fichier de conf...
Dernière modification par AbdelQahar (08-07-2016 12:30:03)
Hors ligne
Hors ligne
Dernière modification par raleur (03-07-2016 22:55:49)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
Dernière modification par Lancelot du Lac (04-07-2016 07:40:54)
Dell Inspiron 7500 series - Debian Stretch - KDE/openbox - ZSH
Samsung - Debian Jessie - LXDE/pas de graphique - ZSH
Hors ligne
Hors ligne
Mais à ce moment-là il va falloir que je modifie les fichiers en étant root.
Oui.
C'est super lourd
Oui, la sécurité c'est super lourd. L'absence de sécurité, on a vu ce que ça a donné avec les versions de Windows où tout le monde a les droits admin.
Au pire tu fais un script qui vérifie si l'utilisateur a modifié l'un de ses fichiers de conf, si oui cp vers /root et tu lances ce script via la crontab root
Du point de vue de la sécurité, c'est guère mieux que de donner à l'utilisateur la permission de modifier directement les fichiers de conf de root. Au final, les conséquences sont les mêmes.
Dernière modification par raleur (04-07-2016 08:09:43)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
To get your usual dot files, make sure that sudo doesn't change the HOME environment variable. Whether this happens depends on the compile-time and run-time configuration of sudo. To preserve HOME, edit the sudoers file (run visudo, never edit this file directly!) and make sure that it contains
Defaults !always_set_home, !set_home
Defaults env_keep+=HOME
(Some of these may be unnecessary depending on compilation options.) And of course don't run sudo -i.
Do avoid doing too much as root though. For example, instead of running an editor as root, use sudoedit.
En gros : faire de sorte que sudo ne modifie pas la variable d'environnement HOME. Comme ça, les fichiers de conf utilisés seront ceux de l'user standart.
Pour ce faire :
Puis ajouter ces deux lignes au fichier :
Et aussi avoir recours à sudoedit plutôt que sudo vim ou sudo nano.
C'est très subtil !
Comment j'ai trouvé ça ? Je me suis rappelé que les fichiers de conf s'appellent "dotfiles" en anglais ("dot" pour point, car le nom de ces fichiers sont précédé pat un point, et sont par conséquent cachés).
Alors j'ai une recherche avec les mots-clés suivants : share dotfiles with root.
EDIT : pour faire cela de manière ponctuelle :
L'option -H permet de préserver la variable HOME.
Dernière modification par AbdelQahar (06-07-2016 20:59:24)
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Mais avec les mêmes risques que de donner à un utilisateur normal la permission de modifier les fichiers de configuration de root.
De toute façon, quel que soit le moyen employé, dès qu'il y a élévation des privilèges, il y a risque potentiel. Je n'utilise pas sudo pour cela, préférant une stricte séparation des accès et des configs.
Mais dans le cadre de cette demande, cela me paraît représenter un moindre mal si sudo est bien configuré, que les fichiers de config ne contiennent pas de paramètres fantaisie et que l'utilisateur bénéficiant de l'élévation des privilèges est conscient de chacune des actions entreprises. Non ?
Hors ligne
Dernière modification par phlinux (07-07-2016 11:24:02)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Il y a aussi la solution du "bind" des fichiers.
C'est plus lourd à mettre en place je trouve. la tu rajoute juste deux ligne au /etc/sudoers pour ceux qui utilise sudo et c'est bon.
Mais avec les mêmes risques que de donner à un utilisateur normal la permission de modifier les fichiers de configuration de root.
Pour ceux qui utilisent sudo, de toute façon le risque est déjà là à cause de la commande -H. Il suffit de le savoir.
Personnellement, après avoir délaisser Ubuntu, j'ai voulu me mettre à une admin "old-school' root/user plutôt que sudouser.
Mais je me suis rendu compte des avantages de sudo à cause de certains scripts que j'ai écris qui avaient besoin que certains parties soient utilisé avec des droits normaux et d'autres avec des droits élevés. Je voulais donc qu'ils soient lancés par un user normal, mais mettre su -c 'truc_muche' partout et devoir mettre son mot de passe à plusieurs reprise, c'est trop lourd. Je suis donc revenu à sudo sauf que je l'ai configuré de la manière suivante :
1 - mon user ne fait pas partie du groupe sudo, je l'ai simplement rajouté dans le fichier /etc/sudoers (c'est permets d'éviter à gksu de taper l'incruste dans toutes les applis graphique nécessitant les droits root, pkexec garde son rôle)
2 - j'ai rajouté l'option rootpw pour que ce soit le mot de passe de root qui soit demandé (ce que je trouve bien plus cohérent)
Parmi les avantages que je vois dans cette méthode :
* simple à mettre en place
* allège le dossier /root puisque il n'y a presque plus rien à mettre dedans au final
* ce ne sont pas les fichiers de root, ce sont les fichiers de l'user dont root se sert
Je passe en résolu tiens.
Dernière modification par AbdelQahar (08-07-2016 12:47:44)
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Au final tu tapes une ligne de commande par fichiers ?
Je ne suis pas sûr d'avoir compris le sens de ta question...
En fait soit tu rajoute les deux lignes dans le /etc/sudoers via la commande visudo.
À ce moment-là, lorsque tu feras sudoedit ou sudo vim par exemple (ou sudo emacs), le fichier .vim (ou .emacs) utilisé sera celui de l'user avec lequel tu as utilisé sudo, pas celui de root.
De même si tu fais sudo -s, le fichier .bahsrc (ou .zshrc pour ceux qui utilisent zsh) sera celui de l'user.
Dans ces conditions, le répertoire /root peut très ne contenir ni .vimrc ni .bahsrc, il n'y a rien à faire de spécial avec les fichier de conf. Pas de ligne de commandes à lancer pour chaque fichier.
J'espère que ça répond à ta question.
Je vais mettre [Résolu avec sudo] plutôt.
Dernière modification par AbdelQahar (08-07-2016 12:48:03)
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne