私はgitoliteにプッシュするなどの方法でDebianサーバーを維持したいと思います。
問題は、gitoliteをrootまたは外部からシステムへのシェルアクセス権を持つユーザーとして実行しないでください。ただし、フックとトリガーでetckeeperと対話するにはgitoliteが必要です（たとえば、外部ユーザーがgit操作を実行する前に、作業ツリーに保留中のすべての変更をコミットしてデフォルトのgitoliteリポジトリにプッシュすることを確認してください）。代わりにルートアクセスが必要です。
何か知りたい安全でシンプルでエレガンスこの問題を解決する方法。
明らかに多くのソリューションが可能ですが、私はLinuxシステムの管理に精通していないので、インスピレーションを探しています。私が考えた考えられる解決策は次のとおりです。
2人の異なるユーザーといくつかのメッセージングシステム（生産者/消費者またはデーモン）を使用して、gitoliteはrootユーザーが実行するように1つのタスクを残します。 （特に終了コードを待つ必要があるため、すべてのコマンドを実行できるシェルスクリプトであるgit Hookの高度な機能に比べて非常に複雑に見えます。）
setuidを使用しますか？この作業のために設計されているようですが、注意深く読んでみると危険に見え、シェルスクリプトをあまりサポートしていないようです。
誰もが正しい方向に私を指すことができますか？
修正する：この質問に対する答えを私が直接見つけて、以下に答えを投稿するようになりました。他の解決策/考察を歓迎します...
答え1
私は次のタイトルのガイドを見つけました。ジトライトとetckeeperしかし、それは私によってテストされていません。
抜粋
多くのLinuxシステムの変更を追跡するために、/ etcのすべての変更を追跡するetckeeperをインストールしました。パッケージをインストールすると、自動コミットのための素晴らしい適切なフックが付属しています。
gitリポジトリの変更を維持することに加えて、gitoliteが管理する中央リポジトリにプッシュし始めました。次の手順でetckeeperを設定しました。
ルート
/etc$ git config –global user.email [email protected] $ git config –global user.name “Configuration Admin” $ git remote add origin [email protected]:machineconfgitキーを
/root/.ssh。rootユーザーとして：
$ cd /etc/etckeeper/commit.d $ (echo ‘#!/bin/sh’ ; echo ‘git push origin’) > 99git-push $ chmod +x 99git-push $ git add . $ git commit -m “automatically push commits to backup repository”
答え2
さて、満月が近づいていて、睡眠不足の私の脳は創造的な過剰運転を始めています。私はこの問題を解決したと思います。
その過程で、私は2番目の重要なセキュリティ問題を発見し、それについて議論します。
質問
gitoliteは変更を/etc/.gitにインポートして確認できるはずです。そのため、権限が必要ですが、外部SSH接続を許可するソフトウェアアカウントであるため、セキュリティ上のリスクがあります。
2番目の問題は、/ etcをgitoliteの鼻の下に渡すことで、gitoliteが読み取らないファイルを読み取って変更できるようにすることです。 Gitoliteは両端に透過的なトランスポートプロトコルでなければなりません。信頼できないブローカー。幸いなことに、これは情報セキュリティの分野でよく研究されたパターンです。
解決策
gitoliteが特権のある制限された操作を実行できるようにするには、実際にはsudoersファイルにそのユーザーを追加し、rootとして実行する必要があるスクリプトのみを実行することを許可できます。 sudoers を使用すると、ルールにハッシュを追加して、ファイル名のみに基づく検証を回避できます。
etcgit ALL=(root) NOPASSWD: sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ== /etc/gitolitetc/scripts/xxx.sh
これにより、etcgitユーザーは1つの操作しか実行できず、1つの操作によってハッシュが改ざんされるのを防ぎます。
それでは、gitoliteの読み取りと/ etc変更の問題について説明します。一部解決策持つ続く〜ある提案済みgitエンドツーエンドを透過的に暗号化します。実現可能であることが証明されれば、すべての問題はすぐに解決されます。
実行可能でない場合でも、gitリポジトリから特定のファイルを省略して、gitoliteがそのファイルを読み取らないようにすることができ、開発者が署名したコミットのみを取得するgitフックを作成できます。つまり、プライベートファイルには/のpgpキーが必要です。 etc/.git 変更を受け入れます。マイクガイツはこれは彼のブログでよく説明されています。署名検証と包括的な理論分析のためのスクリプトが含まれています。
他のいくつかの難解なオプションはまだ妥当性が確認されていないため、Gitoliteがルート所有権の下で制御する必要があるデフォルトのリポジトリを維持し、sudoerを使用してGitoliteが転送操作を実行するために必要な最小限のコマンドのみを実行できるようにすることができます。コミットして渡しますが、リポジトリの内容は実際には読み取れません。これが可能かどうか疑問ですが、可能であれば暗号化されたリポジトリのすべての利点があり、欠点はまったくありません。
まあ、私はついにサーバーの設定を終えたとき、これが当時私の新しいプログラミングブログの最初のブログ投稿の資料になると思いました。