Exécuter un script shell en tant qu'utilisateur différent

42

Quel est un bon moyen d'exécuter un script shell en tant qu'utilisateur différent? J'utilise Debian Etch et je sais quel utilisateur je veux imiter.

Si je le faisais manuellement, je ferais:

su postgres
./backup_db.sh /tmp/test
exit

Puisque je veux automatiser le processus, j'ai besoin d'un moyen d'exécuter backup_db.sh en tant que postgres (hériter de l'environnement, etc.)

Merci!

— Wadih M.
source

67

Pour exécuter votre script en tant qu'autre utilisateur en une seule commande, exécutez:

/bin/su -c "/path/to/backup_db.sh /tmp/test" - postgres

Breaking it down:
 /bin/su : switch user
 -c "/path/to..." : command to run
 - : option to su, make it a login session (source profile for the user)
 postgres : user to become

Je vous recommande de toujours utiliser des chemins d'accès complets dans les scripts tels que celui-ci - vous ne pouvez pas toujours garantir que vous serez dans le bon répertoire lorsque vous suivez (quelqu'un a peut-être changé le répertoire personnel sur vous, qui sait). J'utilise aussi toujours le chemin complet de su (/ bin / su) parce que je suis paranoïaque. Il est possible que quelqu'un puisse modifier votre chemin et vous obliger à utiliser une version compromise de su.

— Baumgart
source

Il faudra toujours que je tape un mot de passe? Comment peut-on le contourner?

— Zjffdu

2

Vous devrez toujours saisir un mot de passe si vous exécutez la commande en tant qu'utilisateur non root. Si vous voulez éviter le mot de passe, vous pouvez configurer sudo pour l'autoriser. CEPENDANT - configurer sudo pour permettre à un utilisateur d’exécuter su leur permet de devenir n’importe quel utilisateur. Je suggérerais de créer un script pour votre commande, de définir les autorisations de script sur 700 et appartenant à root, puis de configurer sudo pour permettre à un utilisateur d'exécuter ce script unique.

— Baumgart

Je crois - bien que cette réponse puisse fonctionner pour le PO - elle n’est pas tout à fait correcte. À ma connaissance, utiliser les deux méthodes -(ou --login) avec --command, -cne démarre pas réellement une session de connexion, car -cforce toujours un shell non connecté.

— JeanMertz

1

Remarque: pour la portabilité, le - postgressdevrait apparaître à la fin de la commande. De la page de manuel:

When - is used, it must be specified before any username. For portability it is recommended to use it as last option, before any username. The other forms (-l and --login) do not have this restriction.

— jonny

23

Si l'utilisateur cible à exécuter a défini nologin shelll, vous pouvez utiliser l'option -s pour spécifier le shell:

/bin/su -s /bin/bash -c '/path/to/your/script' testuser

Voir la question suivante: lancer le script en tant qu’utilisateur disposant du shell nologin

— Basil A
source

9

Pour automatiser cela selon un planning, vous pouvez le mettre dans la crontab de l'utilisateur. Les tâches cron n'obtiendront cependant pas l'environnement complet, mais il serait peut-être préférable de mettre de toute façon toutes les variables d'environnement dont vous avez besoin dans le script lui-même.

Pour éditer la crontab de l'utilisateur:

sudo crontab -u postgres -e

— Kyle Brandt
source

Pourriez-vous s'il vous plaît expliquer plus?

— Saravanakumar

3

Cela devrait être une lecture informative - setuid sur les scripts shell

Si vous exécutez su avec une - usernameséquence d'arguments " ", un shell de connexion sera créé pour permettre à l'utilisateur de fournir le même environnement que l'utilisateur. Habituellement, utilisé pour exécuter rapidement votre script avec votre environnement domestique à partir d’un nom de connexion différent.

— nik
source

Cela peut être utile si vous devez effectuer une série d’actions. Cependant, gardez à l’esprit que la plupart des comptes de service système ne doivent pas avoir de chemins d’accès ni de shells valides.

— Dan Carley

2

Essayez la page de manuel su:

su -c script_run_as_postgres.sh - postgres

Enfin, vous pouvez utiliser sudo pour vous permettre d’exécuter uniquement cette commande en tant que postgres sans mot de passe. Cela prend cependant quelques réglages dans vos / etc / sudoers.

— pjz
source

2

La méthode "su -c ..." publiée par d’autres est une bonne méthode. Pour l’automatisation, vous pouvez ajouter le script à la crontab de l’utilisateur sur lequel vous souhaitez l’exécuter.

— Geoff Fritz
source

1

Si l'utilisateur a déjà une entrée dans sudo et que vous ne connaissez pas le mot de passe du superutilisateur, vous pouvez essayer de suivre: Celui-ci redémarre le postgres initialisé à /data/my-db/pgsql/9.6/data

sudo su - postgres -c "/usr/pgsql-9.6/bin/pg_ctl -D /data/my-db/pgsql/9.6/data -l /var/log/pgsql.log restart"

— smishra
source

-1

Vous pouvez aussi utiliser:

sudo -u postgres script_run_as_postgres.sh

— Xandersoft
source