É possível armazenar o crontab do usuário no repositório git do usuário no OpenBSD?

Question

No OpenBSD e com o cron e crontab , é possível armazenar o crontab(5) de um usuário em um repositório git do mesmo usuário?

Qual seria a maneira correta de realizar algo assim?

(Para direcionar a resposta para a direção correta, eu não me oponho a alterar algumas permissões no sistema, embora prefira não ter que recompilar os binários, nem violar quaisquer paradigmas de segurança.)

    

Answer 1

Todos os crontabs dos usuários são armazenados em um único diretório, e os usuários não podem acessar esse diretório diretamente, eles precisam usar o comando privilegiado crontab .

Em vez de armazenar o arquivo crontab real no controle de versão, escreva um commit hook que executa crontab para enviar a versão mais recente.

crontab "$HOSTNAME.crontab"

O gancho mais simples seria um post-commit hook. Execute git rev-parse --abbrev-ref HEAD para encontrar o ramo atual e 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

Isso não manipula mesclagens ou reorganizações e não registra nada no histórico se crontab falhar. Há um pouco de confronto de paradigma aqui, pois o git tem fundamentalmente vários branches, mas há apenas um único crontab em uma determinada máquina em um determinado momento. Para maior robustez, você pode preferir ter uma ramificação dedicada para crontabs ao vivo e mesclar a essa ramificação quando você alterar o arquivo crontab em sua ramificação de trabalho.

    

Answer 2

Complicado, pois cron procura por crontab arquivos em um único diretório, o que seria inadequado para repositórios git por usuário. Suponho que você poderia substituir /usr/bin/crontab pelo código que, além de emular crontab(1) , descobre quem é o usuário, recupera ou cria seus dados cron armazenados em git, confirma as alterações e disponibiliza esses dados para cron(8) , chamando o original crontab(1) (devido ao bit setgid), ou sendo o próprio setgid (perigo perigo aviso de segurança!). As atualizações do sistema também seriam complicadas, pois durante uma atualização seria necessário deixar o /usr/bin/crontab atualizado instalado e, em seguida, removê-lo para instalar o wrapper ativado por git (e também para quaisquer patches que toquem crontab ).

Os usuários que descobriram onde o original crontab(1) é capaz de ignorar o material do git; para evitar isso, sua implementação teria que ser setgid crontab , o que pode abrir a porta para problemas de segurança arbitrários de sobrescrever-de-qualquer-usuário-crontab ou, em outras palavras, uma ótima maneira de permitir o comprometimento total do sistema (atacante escreve para o arquivo root crontab, eles ganham!) se o seu código contiver algum problema de segurança.

Também é complicado se o usuário descobrir onde está o repositório git por cron e, em seguida, parafusar com isso; Se isso for uma preocupação, eles precisariam pertencer a algum outro usuário, e o cliente crontab(5) personalizado então falaria com algum daemon que tivesse direitos sobre esses repositórios (por exemplo, como sshd faz privsep).

( rcs pode ser suficiente se você só precisa rastrear as mudanças ao longo do tempo, e oferece menos corda para se enforcar do que git .)