怎么查看当前用户的权限详情_Privileges面板使用指南-phpMyAdmin-PHP中文网

whoami和groups是最轻量的用户与组信息查询命令，直接读取进程凭证，毫秒级返回；whoami输出用户名，groups显示所有所属组，包括主组和附加组。

whoami 和 groups 是最轻量的起点

想快速知道“我是谁”“我在哪些组”，whoami 和 groups 就够了。它们不查数据库、不读配置文件，只从当前进程凭证里拿结果，毫秒级返回，且几乎不会出错。

常见错误是误用 who am i ——它依赖终端登录记录，如果是在 systemd 服务、容器或 SSH multiplexing 下运行，可能返回空或过期信息；而 whoami 始终反映内核赋予该进程的实际 UID 对应用户名。

whoami 输出纯用户名（如 ec2-user），可用于脚本变量赋值
groups 显示所有所属组，包括主组和附加组；若需查特定用户，用 groups <username></username>
注意：组成员关系不等于权限——比如在 sudo 组里，只是获得了调用 sudo 的资格，不代表自动拥有 root 权限

ls -l 看文件级权限时别漏掉 umask

用户对文件的“实际可创建权限”不是由账户本身决定的，而是由 umask 和父目录权限共同作用的结果。直接 ls -l 只能看到已有文件的属主/属组/权限位，但看不到用户新建文件时默认被砍掉哪些位。

执行 umask（不带参数）就能看到当前会话的掩码值，比如 0002 表示新文件默认不给组写权限，0022 则连组读都不给。这个值可能来自 shell 配置（/etc/profile、~/.bashrc），也可能被某个启动脚本临时覆盖。

对比 touch a.txt && ls -l a.txt 和 umask 0077 && touch b.txt && ls -l b.txt，能直观看出差异
某些 Docker 容器或 CI 环境中 umask 被设为 0022，导致本该共享的配置文件无法被同组进程读取
umask 不影响已存在文件的权限，只约束新建项

sudo -l 查的是“我能以谁的身份执行什么”

sudo -l 不是查“我有没有 sudo 权限”，而是查“我的用户被明确授权可以运行哪些命令、以哪些用户身份运行”。它是唯一能反映 /etc/sudoers 实际策略的实时命令。

输出里出现 (ALL : ALL) ALL 看似全开，但要注意括号里的冒号分隔：第一个 ALL 是可切换的目标用户，第二个 ALL 是目标用户组；如果写成 (root) /bin/systemctl，就只能以 root 身份运行 systemctl，不能加 -u 指定其他用户。

必须用当前用户执行，切到 root 后再跑 sudo -l 就失去意义
如果提示 no tty present，说明 sudoers 里启用了 requiretty，得加 -S 或改配置
别依赖 sudo -v 判断权限——它只验证密码缓存是否有效，不校验具体命令白名单

PostgreSQL/GaussDB 里 has_table_privilege 是唯一靠谱的权限判断函数

在数据库里查权限，information_schema.table_privileges 只返回显式授予的记录，漏掉角色继承来的权限；而 has_table_privilege() 是 PostgreSQL 和 GaussDB 共享的系统函数，它走的是权限检查引擎真实路径，结果和实际 SQL 执行时的判断完全一致。

调用时注意三参数顺序：has_table_privilege(<user>, <table>, <privilege>)。其中 <code><user></user> 可以是用户名字符串，也可以是 OID；<table> 支持 schema-qualified 名（如 <code>'public.users'）；<privilege></privilege> 必须小写，比如 'select'，写成 'SELECT' 会返回 null。