SOME SPECIAL PERMISSIONS

     Though we usually see an octal permission mask expressed as a three-digit number, it is more technically correct to express it in four digits. Why? Because, in addition to read, write, and execute permissions, there are some other, less-used permission settings.
     The first of these is the setuid bit (octal 4000). When applied to an execut-able file, it sets the effective user ID from that of the real user (the user actually running the program) to that of the program’s owner. Most often this is given to a few programs owned by the superuser. When an ordinary user runs a pro-gram that is setuid root, the program runs with the effective privileges of thesuperuser. This allows the program to access files and directories that an ordinary user would normally be prohibited from accessing. Clearly, because this raises security concerns, the number of setuid programs must be held to an absolute minimum.
     The second less-used setting is the setgid bit (octal 2000). This, like the setuid bit, changes the effective group ID from that of the real group ID of the user to that of the file owner. If the setgid bit is set on a directory, newly created files in the directory will be given the group ownership of the directory rather the group ownership of the file’s creator. This is useful in a shared directory when mem-bers of a common group need access to all the files in the directory, regardless of the file owner’s primary group.
     The third is called the sticky bit (octal 1000). This is a holdover from ancient Unix, where it was possible to mark an executable file as “not swap-pable.” On files, Linux ignores the sticky bit, but if applied to a directory, it pre-vents users from deleting or renaming files unless the user is either the owner of the directory, the owner of the file, or the superuser. This is often used to control access to a shared directory, such as /tmp.
     Here are some examples of using chmod with symbolic notation to set these special permissions.                    
First, assign setuid to a program:
      chmod u+s program
Next, assign setgid to a directory:
      chmod g+s dir
Finally, assign the sticky bit to a directory:
      chmod +t dir
By viewing the output from ls, you can determine the special permissions.
Here are some examples. First, a program that is setuid:
      -rwsr-xr-x
Now, a directory that has the setgid attribute:
      drwxrwsr-x
Finally, a directory with the sticky bit set:
      drwxrwxrwt
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
作者czy1121,源码settingscompat,特殊权限(Special Permissions)兼容库,悬浮窗权限(SYSTEM_ALERT_WINDOW)与系统设置修改权限(WRITE_SETTINGS) Android 6.0 以前只要在 manifest 中申请了权限就是默认开启的 Android 6.0+需要在 manifest 中申请并且通过发送 Intent 让用户在设置界面进行勾选 适配 检测 API 23+(Android 6.0+/M) 使用 Settings.canDrawOverlays, Settings.System.canWrite API 18+(Android 4.3+/JellyBean MR2) 通过反射使用 AppOpsManager.checkOp API < 18 默认权限开启,时始终返回 true 授权 API 23+(Android 6.0+/M) 去系统设置面板就好 new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION), new Intent(Settings.ACTION_MANAGE_WRITE_SETTINGS) API 18+(Android 4.3+/JellyBean MR2) 默认权限开启 API < 18 默认权限开启,不做任何处理 切换授权状态 AppOpsManager.setMode 可用于Android 4.3/4.4修改授权状态 API 18 添加 AppOpsManager(被隐藏,在 Android 4.4 公开) API 21 后需要签名验证的权限android.Manifest.permission.UPDATE_APP_OPS_STATS,第三方应用用不了了。 ROM 有些 Rom 会默认禁用权限,通常都有自带的权限管理 API 18+ 有些 Rom 会默认禁用权限,通常都有自带的权限管理,这时就需要检测 Rom 类型然后跳转到对应的设置页面 API 23+ 本来去系统设置面板就好了,但有些 Rom 会用自带的权限管理替代系统设置面板,这时仍然需要检测 Rom 类型然后跳转到对应的设置页面 实际上是跳转到手机上的安全中心里对应的权限设置页,当安全中心版本不同时相应的权限设置页也有可能不一样 还有部分 ROM 的应用详细信息页可以设置权限
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值