Oublier sudo su
Il n'y a aucun avantage à utiliser sudo su Il s'agit d'une habitude anachronique datant de l'époque où les gens avaient l'habitude d'utiliser le mot "sécurité". su . Les gens ont commencé à s'agglutiner sudo de l'avant lorsque les distros Linux ont cessé d'imposer un mot de passe pour la racine et ont fait de la racine un mot de passe. sudo le seul moyen d'accéder au compte racine. Plutôt que de changer leurs habitudes, ils ont simplement utilisé sudo su . (J'étais l'un d'entre eux jusqu'à une date relativement récente, lorsque j'ai utilisé des boîtes avec des sudoers m'ont obligé à changer mes habitudes).
Utilisation sudo -u
Pour une connexion Shell, sudo -u postgres -i est préférable à sudo su - postgres . Il n'est pas nécessaire que l'utilisateur ait un accès racine à /etc/sudoers Il leur suffit d'avoir le droit de devenir utilisateur postgres . Il vous permet également d'appliquer de meilleurs contrôles d'accès.
Pour l'exécution de la commande
sudo -u postgres psql -c "SELECT 1"
est supérieure à l'alternative :
sudo su - postgres -c "psql -c \"SELECT 1\""
dans la mesure où vous n'avez pas besoin d'échapper les guillemets et autres métacaractères Shell, ainsi que les autres avantages de sécurité liés au fait que vous n'avez pas besoin de l'utilisateur root. Vous finirez probablement par écrire accidentellement :
sudo su - postgres -c psql -c "SELECT 1"
parfois, ce qui ne fonctionnera pas correctement.
Enfin, il est beaucoup plus facile de définir des variables d'environnement via sudo , par exemple
sudo PATH=/usr/pgsql-9.3/bin:$PATH -u postgres /usr/pgsql-9.3/bin/initdb -D /var/lib/pgsql/testcluster
que par l'intermédiaire de su . (Ici, le PATH est nécessaire pour que initdb peut trouver la bonne postgres exécutable).
Donc. Oubliez les su existe. Vous n'en avez plus besoin. Pour rompre avec cette habitude, donnez-lui un alias qui affichera une erreur. (Certains scripts scripts utilisent encore la commande su (vous ne pouvez donc pas l'enlever).
Voir aussi
