小历史
Gitolite作者受Gitosis的影响.用perl实作了一个lite版的Gitosis.
但是后来发现功能越来越多,现在已经比Gitosis还要强大了.也早已不lite了.
Gitosis现在也已经不再维护,或者说没有动静了. 但是他们的原理其实是一样的.
如果失去了Gitolite世界会怎么样
像github这样的靠Host Repos赚钱的公司,如何才能给成千上万的用户提供服务呢?
它要为每个人在github服务器上建立一个用户,然后将用户的key添加到对应服务器账户的authorized_keys里面.
如果该用户需要collaborator,ok,需要把collaborator同样添加到authorized_keys里面.
这样的话所有人clone repo就会变成类似这样的方式:
git clone saito@github.com:repo.git
github现在clone的方式是:
git clone git@github.com:saito/repo.git.
所以基本可以确定github肯定不至于这么圡.
如果用户只需要这个collaborator有自己一个repo的读写权限,怎么办? 对不起,没办法.
一旦给collaborator放权,他就拥有了该用户所有repo的控制权限.这样几乎是不可用的.
依靠这种为每个人建立用户的方法管理几乎是不可维护的.如果没有类似Gitolite的产品,也不可能造就github这样的公司.
Git默认是ssh协议
既然是ssh协议,那么,用户访问服务器就要用类似ssh-copy-id的方式把自己的key加入服务器的authorized_keys里面.
从github的clone repo的方式,基本可以确定,github在服务器上是有一个名为git的用户在管理所有人的repo的.
如果只有这么一个用户,所有人的key都要被添加到git用户的authorized_keys里面.那么如何做权限控制呢?
SSH triggers拯救世界
假想我们拿到一个正常authorized_keys文件:
ssh-rsa key-blob git@github
这里我省略了长长的key-blob.
Magic Thing:
command="mkdir -p ~/ssh/boom" ssh-rsa key-blob git@github
将authorized_keys文件行头加上
command="mkdir -p ~/ssh/boom"
保存authorized_keys文件,重新ssh到服务器.
这时候神奇的时候发生了,用户的home下面将会得到一个~/ssh/boom目录.
利用自己的想象力,想想这个可以干什么坏事?
(提醒大家,安装软件要小心,bumblebee随时都可能出现在你身边.)
Gitlite/Gitosis用它干了什么好事呢:
截取一段Gitosis所控制的authorized_keys文件:
command="gitosis-serve git@github",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa key-blob git@github
no-pty的意思是不建立伪终端.
这里Gitosis所作的事情是调用自己写的一个函数/脚本:
gitosis-serve, 然后传入用户的标识.
在脚本
gitosis-serve中,Gitosis有一个参数是用户标识,还有用户来请求的命令.这里假设命令是:git clone git@localhost:repo.git
gitosis-serve会利用正则截取用户要请求的repo,然后将用户标识与repo在自己的conf文件里做匹配.
看是否用户有相应的权限.
对应的命令还有pull push等也会有相应的R W权限做判断.
这样就把原本要在authorized_keys里做的权限控制,通过ssh triggers转移到了自己的脚本里面.
然后通过gitosis的配置文件来做所有项目的权限管理.
值得一题的是,Gitosis与Gitolite都将自己的管理文件也放在一个git repo里面.
所有对配置文件的操作也都变成了对一个git仓库的操作.通过hook来在更新配置后相应修改authorized_keys.
结语
希望可以有pure ruby的gem,这样结合grit就可以做更多更方便的管理了.
当然是对于rubyist来说..
ssh真的是常挖常新...
https://github.com/sitaramc/gitolite/wiki
https://github.com/sitaramc/gitolite/wiki
没有评论:
发表评论