对struct cred新理解

到现在我还没有看到cred被加入内核的mainline，可惜啊，不过我个人认为它是很不错的，其精髓就是补丁 上的那一句，就是将权力和授权分离，这句话看似有点不知所云，难道权力不就是授权吗？其实是不一样的，权力有一种与生俱来的意思，它是客观的东西，所谓天 赋人权是也，而授权有种主观的意思，它可能是暂时的，就是说为了使得你可以完成某项特定的工作而暂时给你一些权力，然后给你授权的实体还是可以剥夺这种暂 时给你的权力的，与之相反，权力就不能被剥夺，因为它不是别人授予的，而是与生俱来的，如果说可以剥夺或者改变，那也只能是自己来，别人可以影响的只有你 的授权。
linux的cred补丁就是将一些授权放到了一个struct cred结构体中了，这个结构体是：
struct cred {
atomic_t usage;
uid_t uid; //这个就是该cred被授予的uid
gid_t gid; //该cred被授予的gid
struct rcu_head exterminate;
struct group_info *group_info;
};
这 个cred叫做什么比较好呢？其实它就是一张认证或者令牌，cred可以被单独制作和分发，比如可以制作一张uid为0，gid为0的root认证的 cred，如果需要检查授权的地方只需要检查这个cred结构体就可以了，此时执行绪本身的uid并没有变，不会因为授权了一个新的uid就可以胡作非为 了，授权给他的这个cred是让它做特定的事情的，其实也仅仅是这个特定的事情才会以这个cred中的uid或者别的字段作为判断权限的依据。这个特性有 什么用呢？想象一下现在的nfs的rpc实现，最后的网络传输和数据读取是靠一个守护进程完成的，普通应用nfs的用户进程只不过是接口vfs而已，底下 就是另外的进程的事情了，于是rpc中有复杂的授权体系，如果按照这个补丁的想法，这将是多么简单，直接将一个cred给了一个底层运用rpc的用户进 程，该cred中有必要的授权。另外再看看文件访问，如今在task_struct中有专门的fsuid字段负责这个授权，虽然没有什么不好，但是想想总 是不是那么直观，我们看一下用cred怎么实现：
void change_fsuid(struct cred *cred, uid_t uid)
{
cred->uid = uid;
}
然后在访问的时候就在特定的文件系统中判断current的cred中的uid就可以了，而且这个cred随时可以被任何实体更换，任何实体都可以给任何进程任何授权，并且还可以剥夺相应的授权，美妙啊！如果在内核中用上这个特性该有多好。