Exécution de tâches nouvelles en tant qu'utilisateurs non privilégiés

Quelle est la manière canonique de faire en sorte qu'un travail parvenu modifie son ID utilisateur et exécute le script en tant qu'utilisateur non privilégié?

Évidemment, on peut utiliser suou sudo, mais cela semble hacky (et peut générer des lignes de journal inutiles).

Avec upstart v1.4, setuid et setgid sont supportés de manière native dans le fichier de configuration.

En posant sur la chaîne #upstart sur freenode, la question officielle est la suivante:

La prochaine version d'Upstart aura un support natif pour cela, mais pour l'instant, vous pouvez utiliser quelque chose comme:

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

Que diriez-vous d'utiliser start-stop-daemon?

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd

Du livre de cuisine Upstart :

La méthode recommandée pour les systèmes Debian et Ubuntu consiste à utiliser l'utilitaire d'assistance start-stop-daemon. […] start-stop-daemonN'impose pas de limites au processus démarré par PAM ("Pluggable Authentication Module").

Remarque: start-stop-daemonnon pris en charge par RHEL.

Il existe plusieurs façons de le faire, toutes avec une sémantique légèrement différente, en particulier en ce qui concerne l'appartenance à un groupe:

• setuidgid vous mettra dans le groupe que vous spécifiez.

  • Les outils originaux de daemontools setuidgidne vous placeront que dans ce groupe, vous ne pourrez donc pas accéder aux fichiers appartenant aux autres groupes dont vous êtes membre.
  • Les outils setuidgidfrom daemontools-encore et setuidgidfrom the nosh ont tous deux une option -s(aka --supplementary) qui vous placera dans ce groupe et vous placera également dans tous les groupes supplémentaires de l'utilisateur que vous spécifiez.

• Utiliser newgrpune fois que vous êtes devenu l'utilisateur le moins privilégié ajoutera un seul groupe à votre groupe, mais créera également un nouveau sous-shell, ce qui rendra l'utilisation du script difficile.

• start-stop-daemon préserve votre appartenance à un groupe et fait beaucoup plus que simplement setuid / setgid.

• chpst -u username:group1:group2:group3... commandnamevous permettra de spécifier exactement les appartenances à un groupe à adopter, mais (dans Ubuntu ), il est uniquement fourni avec le runitpaquet, qui est une alternative à upstart.

• su -c commandname usernamerécupère tous les membres du groupe de noms d'utilisateur, comme c'est le cas sudo -u username commandname, de sorte qu'ils sont probablement la voie la moins étonnée.

Utilisez setuidgiddu paquet daemontools.

Documentation ici: http://cr.yp.to/daemontools/setuidgid.html

Sur une instance Ubuntu 10.10 sur Amazon EC2, j'ai eu plus de chance avec la start-stop-daemoncommande.

J'ai également eu du mal avec certaines des autres strophes avancées . J'appelle une application python avec un virtualenvparamètre spécifique et certains paramètres de mon programme exécuté.

Ce qui suit est ce qui a fonctionné pour moi.

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script

Il PYTHONPATHconsiste à installer certains packages à partir de la source dans le chemin du module PYTHON lors de l’exécution de cette tâche. Je devais tout faire de manière absolue parce que la chdirstrophe ne semblait pas fonctionner.

J'utilisais CentOS 6 et je ne pouvais pas utiliser le hack recommandé (pour Upstart 0.6.5), ni le truc "su" car le nombre de fourches impliquées (4 je pense) n'était pas suivi par "expect fork" 'ou' attendons le démon '.

J'ai finalement juste fait

chown user:group executable
chmod +s executable

(c.-à-d. définir le bit setuid et changer la propriété).

Ce n'est peut-être pas la méthode la plus sûre, mais dans le cas d'un projet interne de R & D, peu importait.

Il y a une troisième possibilité en fonction de ce que vous essayez d'accomplir. Vous pourrez peut-être relâcher les contrôles d’accès sur les fichiers / périphériques en question . Cela peut permettre à un utilisateur non privilégié de monter ou d'accéder à des éléments auxquels il ne serait normalement pas autorisé. Veillez simplement à ne pas donner les clés du royaume dans le processus.

Vous pouvez également modifier le délai d'expiration du cache de mot de passe sudo . Mais je ne le recommande pas, sauf si votre machine est physiquement sécurisée (vous pensez qu'il est peu probable qu'un passant tente d'obtenir un accès sudo).

Il y a une bonne raison qu'il ya très peu de moyens d'effectuer des actions privilégiées et qu'ils exécutent inutiles nécessaires l' exploitation forestière. Des restrictions lâches constitueraient un risque pour la sécurité de votre système, et l'absence de journalisation signifierait qu'il est impossible de savoir ce qui s'est passé lorsque vous avez été compromis.

Si la taille de vos fichiers journaux pose problème, il est probable que quelque chose ne va pas. Sudo génère une seule ligne par utilisation dans des conditions normales.

Dans CentOS 6, jusqu'à 0.6.5, voici ce qui a fonctionné pour moi.

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script

ou :

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script

Quand utiliser

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

le processus de travail ne peut pas être arrêté par initclt stop. Je pense que la raison est:

1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`