拿到一个webshell，权限第一件事不是权限急着翻文件，而是权限看权限。`whoami`敲下去，权限回显`www-data`，权限心里就凉了半截——Linux下这个用户基本就是权限个受气包，读不了/etc/shadow，权限写不了/root，权限连很多敏感目录的权限门都摸不到。但反过来，权限要是权限回显`root`或者`system`，那感觉就像捡到一把万能钥匙，权限整个系统对你来说就是权限透明的。

权限这东西，权限在webshell场景里比漏洞本身还关键。权限我见过太多人费劲拿到shell，结果卡在权限上动弹不得。有个朋友之前搞下一个站，webshell是PHP的，执行命令没问题，但`cat /etc/passwd`能看，`cat /etc/shadow`直接permission denied。他折腾半天想提权，内核版本又太新，最后只能拿着个低权shell干瞪眼。

Windows那边更明显。`whoami /priv`一跑，如果看到`SeImpersonatePrivilege`或者`SeAssignPrimaryTokenPrivilege`，恭喜你，Potato系列工具可以直接上了。这些令牌权限在IIS或者Apache的服务账户下经常默认开启，配合JuicyPotato或者RoguePotato，提权成功率相当可观。但要是这些特权都被阉割了，那就得另想办法。

Webshell的权限还跟它的运行环境绑死。PHP以模块方式跑在Apache下，权限就是Apache进程的权限；跑在php-fpm里，就是fpm池配置的用户。有时候同一个服务器上，不同站点的webshell权限天差地别——一个可能是nobody，另一个配置不当直接就是root。这种差异往往比漏洞本身更有利用价值。

说个具体的。去年帮人看一个站，WordPress的，插件漏洞上传了webshell。`id`一看，`uid=33(www-data) gid=33(www-data)`。常规操作，翻wp-config.php拿数据库密码，然后尝试连数据库。结果MySQL只允许localhost连接，而且这个www-data用户没有写文件的权限。想用`SELECT ... INTO OUTFILE`写个马到web目录，失败。想读/etc/shadow，没门。

后来注意到`/tmp`目录权限是777，而且系统上有个定时任务脚本，root权限跑的，会去/tmp下读一个特定名字的文件。等了几分钟，脚本执行，直接反弹了一个root shell回来。整个过程没用什么内核漏洞，就是权限配置的疏忽。webshell本身的权限低不要紧，关键是它能看到什么、能写什么、能触发什么。

再提一个容易忽略的点：webshell的权限还受限于SELinux和AppArmor。CentOS上SELinux enforcing模式，就算你是root，httpd进程也只能在特定上下文里活动。`ls -Z`看一眼，`httpd_sys_content_t`的目录你随便读，但想写`httpd_sys_rw_content_t`以外的地方，门都没有。这时候提权到root也没用，得先想办法把SELinux关了或者改策略。

所以拿到webshell，别急着当管理员。先搞清楚自己是谁、能干什么、系统上还有什么在跑。权限不是静态的，是动态的——一个低权shell配合正确的信息收集，往往比一个高权但被限制得死死的shell有用得多。我见过有人拿着root webshell却因为SELinux和只读文件系统，连个后门都种不进去，最后只能靠内存马苟着。

权限决定了webshell的玩法。低权有低权的路子，高权有高权的风险。真正重要的是理解当前权限边界在哪，边界之外有什么，以及怎么用现有的权限去撬动更大的控制权。这比单纯追求一个root shell要实在得多。