これを実装するには、2つの補完的な方法があります。
gitリポジトリをリモートで使用する権限をユーザーに付与する
gitolite3ハブライブリポジトリスキーマ（詳細はここで説明）を提供するために使用します。これには、ユーザーが同じリポジトリのプッシュ/プルおよびチェックアウトバージョンを実行できるようにするbareリポジトリ（ハブリポジトリ）が必要です。（ライブリポジトリ）/srv/www/htmlたとえば、適切なパスにあります。
ハブリポジトリのgitolite3処理に使用したいのですが、必須ではありませんが、必要に応じて、選択したLDAPにきめ細かいアクセス制御をバインドすると便利です。ブランチレベルまで細かく制御できます。gitolite3
をgitolite3介してユーザーの機能を制限し、呼び出しsudoによってフックを処理することもお勧めしsudoます。これはgitolite3フックを使用した実際の例です（必要に応じて、自由に変更するか、拡張または修正してください）。
/etc/sudoersまたはの関連コンテンツは、次の/etc/sudoers.d/gitolite3ようなものになります。
Cmnd_Alias GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /usr/bin/xargs, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Cmnd_Alias GITOLITE_APACHE_CMDS = /usr/sbin/apachectl graceful
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3 ALL = (root)NOPASSWD: GITOLITE_CMDS
gitolite3 APACHE_HOSTS = (root)NOPASSWD: GITOLITE_APACHE_CMDS
ハブレポpost-updateフック：
#!/bin/sh
echo "****"
echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
echo "****"
sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"
exit 0
publisher-hub2live 脚本：
#!/bin/sh
echo "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
echo "****"
cd "$1" || exit
umask 0022
unset GIT_DIR
/usr/bin/git pull hub master
# custom actions here
# e.g call grunt tasks
/bin/chown -R "$2" "$1"
/bin/find "$1" -type d -exec chmod "$3" {} +
/bin/find "$1" -type f -exec chmod "$4" {} +
/bin/chmod u+x "$1"/.git/hooks/post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info
exit 0
ログインシェルで許可されていないコマンドを実行する機能を制限する
実装する必要があるのは、厳密に許可されている以外のアクションを実行するユーザーの能力を制限する、再現可能で監査可能な方法です。
これは必須ではありませんが、ユーザーをLDAPに登録していて、PAMモジュールを使用するか、freeIPAおよびを使用して、LDAP認証を実行するメカニズムをすでにデプロイしている場合に役立ちますsssd。
このシナリオを実装するために、私が現在行っていることは次のとおりです（この種の制限は、いくつかの条件を満たす必要があることに注意してください。それ以外の場合、制限は簡単に回避できます）。
- ユーザーは
wheelグループに属しておらず、使用が許可されている唯一のユーザーですsu（PAMを介して適用されます）。通常、非LDAPユーザー（sysadm）は、信頼できる管理者が災害復旧またはLDAPが利用できない場合にアクションを実行できるようにするために存在します。
ユーザーにはrbash、プライベートを指す読み取り専用のPATHで適切に保護されており~/bin、この~/bin/ディレクトリには、許可されているすべてのコマンドへのリンクが含まれています。次に例を示します。
$ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud 7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud 8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 git -> /usr/bin/git*
lrwxrwxrwx. 1 root dawud 9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
ユーザーが制限され、読み取り専用の環境を与えられている（のようなものを考えるLESSSECURE、TMOUT、HISTFILE変数）。これは、のshellようなコマンドからのエスケープを回避しless、監査性を確保するためです。
rvim同じ理由で、許可される編集者はだけです。ユーザーが実行できるのはsudoedit、構成で実行rvimするように構成されている場合のみsudoです。
Defaults editor=/usr/bin/rvim
MAC制限が設定されている場合（使用している特定のGNU / LinuxディストリビューションでSELinuxが有効になっている場合）、ユーザーはSELinuxユーザーにマップされ、staff_uを介して必要に応じて他のユーザーとしてコマンドを実行する権限が与えられますsudo。特定のsudorules許可は、ユーザーがこれらの制限を回避することを防ぐために注意深く検討する必要があり、既存のLDAPインフラストラクチャに展開することもできます（これはfreeIPA機能の1つです）。
ユーザーの/home、/tmpそしておそらく/var/tmpポリインスタンス化され/etc/security/namespace.confます：
/tmp /tmp/.inst/tmp.inst-$USER- tmpdir:create root
/var/tmp /tmp/.inst/var-tmp.inst-$USER- tmpdir:create root
$HOME $HOME/$USER.inst/ tmpdir:create root
ディレクトリの多インスタンス化は新しい機能ではなく、かなり長い間利用可能でした。参照として、2006年のこの記事を参照してください。実際のところ、多くのモジュールはpam_namespaceデフォルトですでに使用されていますが、のデフォルト設定で/etc/security/namespace.confはポリインスタンス化が有効になっていません。また、/etc/security/namespace.initすべてのスケルトンファイルをユーザーに対して読み取り専用にし、が所有するようにする必要がありrootます。
このようにして、ユーザーが自分の代わりにコマンドを実行できるか（上記で説明したように、を~/bin介してプロビジョニングされたプライベートディレクトリのリンクを介して/etc/skel）、他のユーザーの代わりに（を介してsudo）コマンドを実行できるか、まったく実行できないかを選択できます。