cred

cred这个机制背后的思想，就是“使得主体和客体分离”。

这个思想是很自然的，主体和客体分离总是一件好事，这样可以不至于使事情变得不可控制，但是在设计一个系统的时候，我们往往不能一开始就做到这一点，必然经过一次次地筛选过滤之后，才可以将留下来的东西重新组合，最终做到主体和客体分离，就好比我们盖一座房子，必然的一开始我们不能将房子一块一块的运过来只要组合就行，而是必须运过来水泥，沙子，钢筋，然后融入设计师的思想，这样房子才可以成型。在linux内核的演变中，如果说一个机制引入了内核，那么在实现该机制的最开始的几个版本中，该机制的角色就是水泥，沙子，钢筋，到了后面的版本，这些机制才得以脱俗，成为linux内核中的艺术，linux内核就是这么发展起来的，到如今，里面的很多机制都是艺术。

我们都知道，linux中进程的重要性，几乎所有的任务都要给它一个进程上下文，即使现在还没有给，linux内核的设计者也有这样的想法，既然进程如此重要，那么就有必要给它一些限制字段用来进行一些安全上的限制，毕竟你可以让进程做好事也可以让进程做坏事。其实多任务，多用户都是用进程实现的。linux自原始以来就继承了unix的良好基因，在进程控制结构即task_struct中就拥有了uid，gid等信息用来区分用户和组从而实现基本的安全控制，进一步，uid，gid机制加上unix/linux的fork/exec机制一起实现了真正的多用户/多任务机制，咋看起来，uid和gid等理应是一个进程的属性，理应在task_struct里面存在，可是我们能否将之向更高的高度抽象一下呢？想象一下我们为何可以用uid和gid等实现多用户，多用户最基本的是什么？这些问题可以归结为安全，信任，所谓的多用户最基本的就是信任问题，因此完全可以为uid，gid，以及诸多安全信任相关字段设置一个新的独立的结构，这个结构就是struct cred，这样看来task_struct就更加规整了，抽象程度更高了，而不像以前那样所有东西都往里面堆积了。前面是从设计上来说的，那么这么做是否必要呢？有这方面的需求吗？值得注意的是，如果没有需求，linux内核很难仅仅从设计上进行更改，这就是linux内核的风格。

在新内核中，将要加入的一个新机制就是cachefs，这很显然是个和缓存相关联的文件系统，其实它的出现是为了平衡各种底层文件系统的速率的差异，众所周知，nfs的数据来自远程，另外一台机器上可以并存告诉磁盘和低速磁带，这些底层文件系统的差异要求内核提供一个适配层来平衡这些差异，当然这个适配层是可选的，如果你不嫌一些文件系统慢，那么完全可以不用，这里的平衡仅仅针对慢速文件系统缓存数据，而不会将本来就很快的文件系统的速率降低，它实际上就是在快速磁盘上划分一块区域，这块区域专门用来缓存慢速文件系统的数据，这样的话如需读写慢速文件系统的数据就直接可以操作缓存文件系统了，然后的同步操作就是内核机制的事情了，其实就是缓存文件系统的事情，到了这一步就没有用户空间进程的什么事情了，注意缓存文件系统和内核中的address_space实现的页高速缓存是两码事，它们根本就不是一个层次的，缓存文件系统是页高速缓存的下层，它们其实没有交集。现在看看实际情况，cachefs的管理很复杂，牵扯到许多用户的策略，于是在用户空间就要有一个守护进程来实现cachefs的管理，毕竟涉及策略的问题还是让用户空间来实现吧，既然用户守护进程实现了管理，cachefs中缓存的文件就是由这个守护进程来创建，删除，修改了，那么该cachefs中的文件的uid，gid以及安全字段就是这个守护进程的了，但是这些文件虽然由守护进程创建却不是让守护进程访问，而是让所有和慢速文件系统交互的进程来访问用以提高速度的，于是问出来了，普通进程可以访问cachefs中的文件吗？毕竟它们的uid，gid，访问令牌不同啊，不是一个进程的，那该怎么办？于是将进程的安全元素抽象出来的需求被提了出来，这样的话就可以做到随时更新替换安全元素了而不用为了访问一个文件在task_struct中更改那么多东西了，这样的话，如果普通进程访问了cachefs的中缓存的文件，那么就把该进程的安全信用元素替换成负责cachefs管理的守护进程的安全信任元素以获得cachefs中文件的访问权，完事之后再替换过来，这是不是很简洁的解决了这个问题啊？现在看一下内核补丁的实现，其中这个补丁中最重要的就是get_kernel_cred了：

struct cred *get_kernel_cred(const char *service, struct task_struct *daemon)

{

struct cred *cred, *dcred;

int ret;

cred = kzalloc(sizeof *cred, GFP_KERNEL);

if (!cred)

return ERR_PTR(-ENOMEM);

if (daemon) {

rcu_read_lock();

dcred = task_cred(daemon);

cred->uid = dcred->uid;

cred->gid = dcred->gid;

cred->group_info = dcred->group_info;

atomic_inc(&cred->group_info->usage);

rcu_read_unlock();

} else {

cred->group_info = &init_groups;

atomic_inc(&init_groups.usage);

}

ret = security_cred_kernel_act_as(cred, service, daemon);

if (ret < 0) {

put_cred(cred);

return ERR_PTR(ret);

}

return cred;

}

参数daemon代表一个进程，在任何一个进程上下文中调用这个函数，将需要拥有需要的安全信任元素的进程作为daemon传入函数，得到的就是包含该daemon安全信任元素的一个新结构，把这个结构设置进调用上下文的进程的task_struct，则调用上下文的进程就拥有了daemon的安全信任元素，就可以做一部分只有daemon才可以做的事情了，其实此时可以认为是调用上下文在代表daemon做事，结合上面提到的cachefs的例子，不是说任意进程可能无法都获得cachefs的文件的访问权吗，那么在cachefs的内核代码中调用上述的get_kernel_cred和另外的一个函数set_current_cred，这样的话事情就成了。最后值得注意的就是，新内核的cred结构体其实就是将原先task_struct中的一些涉及安全和信任的字段包装成了一个结构，该结构可以动态的设置和替换，在代码细节上运用到了RCU锁，其实这个新机制的本质就是利用了RCU，这个的原因就是为了防止过多的竞争，新内核规定，cred中的字段在cred没有脱离task_struct的时候不能改变，也就是说如果你想改变当前进程的cred中的字段，你就必须先将它搞一个副本下来，然后只能改副本，最后再把副本放上去，这就是RCU的机制，就不多说了。

早在去年我就听说了windows vista可以实现动态的能力赋予，也就是说不必为了删除一个重要文件而获得整个管理员的权限，而是只获得删除这个文件的权限就可以了，开始的时候我对这个机制十分感兴趣，心想linux为何就不能呢，实际上linux完全可以做到，你可以用两种方式实现，第一就是用户空间的方式，这个涉及到安全配置管理，另一个就是内核的方式，这个涉及到linux的LSM机制，在最新的2.6.29内核上，cred机制可以更加简单的实现这一点，因为作为一个整体struct cred中可以只更改某些字段而不必触及所有，当然实现这个需要LSM的帮忙，总之，linux就是十分灵活