标签：
之所以会说到这几个特殊权限，是因为fastboot这个命令好像有点抽风，给人的感觉就是有时能用有时不能用，执行fastboot devices的错误提示：
no permissions
为了找到问题的原因，就思考了一下。
这种问题一般主要发生在以下2种场景下：
1、复制并使用了新的fastboot可执行文件
2、改变了fastboot可执行文件的环境变量
为什么以上2种场景会产生这样的错误？
which fastboot ll fastboot
执行这两条命令之后就可见端倪，原来由于复制或者使用了别人复制的fastboot，导致fastboot所属的用户和群组发生了改变，从而让SUID和SGID失效，因为原来fastboot所属的用户和群组都是root。
接下来我们就简单说了解一下SUID和SGID的失效导致no permissions背后的知识点。
Set UID，它会出现在文件拥有者权限的执行位上，只对二进制程序有效，执行者对于程序需要有x权限，在程序运行过程中，执行者拥有程序拥有者的权限。
例如：普通用户执行fastboot和passwd命令。
这里再多说一句，很多Android上的root工具就是通过一些漏洞（比如缓冲区溢出等）来攻击一些带有SUID或SGID权限，并且所属的用户或用户组是root的二进制程序来临时获取root权限，然后执行一段事先编译好的恶意目标平台代码来达到root的目的。
Set GID，它出现在文件所属组权限的执行位上面，对于文件和目录都有效，具体作用如下：
1、对于文件
对于二进制程序有用，程序执行者要有x权限，执行者在执行过程中会获得该程序用户组的权限（相当于临时加入了程序的用户组）
2、对于目录
用户对此目录有rx权限可以进入目录，用户进入此目录后，有效用户组会变成该目录的用户组，若用户在此目录有wx权限，则用户创建的文件的用户组与该目录用户组相同。
一个小问题背后也会隐藏一些比较重要的知识点，善于发现和总结，总能有一些收获。
最后，将此问题记录下来，希望能够帮到后续遇到类似问题的同学。
由Android的fastboot no permissions而引出的Linux特殊权限管理之：SUID、SGID、SBIT
标签：
原文地址：http://blog.csdn.net/songjinshi/article/details/46593433
