Est-il possible de stocker le crontab de l'user dans le référentiel git de l'user sur OpenBSD?

Tous les crontabs des users sont stockés dans un seul directory et les users ne peuvent pas accéder directement à ce directory, ils doivent utiliser la command privilégiée crontab .

Au lieu de stocker le file crontab dans le contrôle de version, créez un crochet de validation qui exécute crontab pour envoyer la dernière version.

 crontab "$HOSTNAME.crontab" 

Le crochet le plus simple serait un crochet post-commit . Exécutez git rev-parse --abbrev-ref HEAD pour find la twig courante et git show --format=format: --name-status HEAD .

 #!/bin/sh commit=$(git rev-parse HEAD) branch=$(git rev-parse --name-status "$commit") git show --format=format: --name-status "$commit" | while read -r status filename; do if [ "$branch" = "master" ] && [ "$status" = "A" -o "$status" = "M" ] && [ "$filename" = "crontabs/$HOSTNAME.crontab" ]; then crontab "$filename" fi done 

Cela ne gère pas les fusions ou les rebases, et n'enregistre rien dans l'historique si crontab échoue. Il y a un peu de paradigme ici car git a fondamentalement plusieurs twigs mais il n'y a qu'un seul crontab sur une machine donnée à un moment donné. Pour plus de robustesse, vous préférerez peut-être disposer d'une twig dédiée aux crontabs actifs et merge avec cette twig lorsque vous changerez le file crontab de votre twig de travail.

Compliqué, car cron search les files crontab sous un seul directory, ce qui ne conviendrait pas aux référentiels git par user. Je suppose que vous pouvez replace /usr/bin/crontab par du code qui, en plus d'émuler crontab(1) , détermine qui est l'user, récupère ou crée ses données cron git-stockées, données disponibles à cron(8) , soit en appelant le crontab(1) origine crontab(1) (en raison du bit setgid), soit en configurant lui-même (avertissement de danger de security!). Les mises à jour du système seraient également compliquées, car au cours d'une mise à jour, il faudrait laisser la mise à jour /usr/bin/crontab installée, puis l'installer pour installer votre wrapper git-enabled (ainsi que pour les patchs qui touchent crontab ).

Les users qui ont compris où le crontab(1) origine crontab(1) est capable de contourner les trucs git; pour éviter cela, votre implémentation devrait être setgid crontab , ce qui peut ouvrir la porte à des problèmes de security arbitraires-overwrite-of-any-users-crontab-files ou en d'autres termes un excellent moyen de permettre un compromis total du système (l'attaquant écrit root crontab, ils gagnent!) si votre code contient des problèmes de security.

Il est également compliqué si l'user détermine où se trouve son référentiel git per-cron, puis se returnne avec cela; si cela pose un problème, ceux-ci devront être possédés par un autre user, et le client crontab(5) parlera alors à un démon qui possède des droits sur ces référentiels (par exemple, comment sshd fait privsep).

( rcs peut suffire si vous avez simplement besoin de suivre les changements dans le time, et offre less de corde pour vous pendre qu'avec git .)