Exécution de travaux upstart en tant qu'utilisateurs non privilégiés

Sur une instance Ubuntu 10.10 sur Amazon EC2, j'ai eu plus de chance avec l'option start-stop-daemon comando.

J'ai aussi eu du mal avec certains des autres nouveaux venus. strophes . J'appelle une application Python avec une adresse spécifique. virtualenv et quelques paramètres à mon programme exécuté.

Voici 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

El PYTHONPATH est de faire en sorte que certains paquets soient installés à partir de la source dans la Python le chemin du module lorsque ce travail de démarrage s'exécute. J'ai dû tout faire dans des chemins absolus parce que le module chdir La strophe n'a pas semblé faire l'affaire.

J'utilisais CentOS 6, et je n'ai pas pu faire fonctionner le hack recommandé (pour Upstart 0.6.5), ni l'astuce 'su' parce que le nombre de forks impliqués (4 je pense) n'était pas suivi par 'expect fork' ou 'expect daemon'.

J'ai fini par le faire.

chown user:group executable
chmod +s executable

(c'est-à-dire mettre le bit setuid et changer la propriété).

Ce n'est peut-être pas la méthode la plus sûre, mais pour un projet interne de R&D, cela n'avait aucune importance dans notre cas.

Dans CentOS 6, upstart 0.6.5, ce qui suit est 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`

Il existe une troisième possibilité, selon ce que vous essayez d'accomplir. Vous pouvez être en mesure de desserrer les contrôles d'accès sur les fichiers/appareils 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é. Assurez-vous simplement que vous ne donnez pas les clés du royaume dans le processus.

Vous pouvez également changer le timeout du cache du mot de passe sudo . Mais je ne le recommande pas à moins que votre machine soit physiquement sécurisée (c'est-à-dire que vous pensez qu'il est peu probable qu'un passant tente d'obtenir un accès sudo).

Ce n'est pas pour rien qu'il y a très peu de façons d'effectuer des actions privilégiées et qu'elles exécutent inutile nécessaire l'exploitation forestière. Des restrictions trop lâches constitueraient un risque pour la sécurité de votre système, et l'absence de journalisation signifierait qu'il n'y a aucun moyen de savoir ce qui s'est passé lorsque vous avez été compromis.

Si le taille de vos fichiers journaux est un problème, alors il y a probablement un problème. Sudo ne génère qu'une seule ligne par utilisation dans des conditions normales.