如何确定Linux下当前用户的认证授权来源？

核心结论 #

内核和GLIBC没有直接能查询用户认证源的API。因为用户的UID/GID是认证完成后赋予的凭证，内核只管维护这些凭证，不会记录获取凭证的具体认证方式。

为什么查不到相关接口？ #

• 认证是用户态PAM模块的活儿：PAM框架本身跑在用户态，不同的认证源对应不同的PAM模块——比如pam_unix.so对应本地passwd/shadow文件，pam_krb5.so对应Kerberos，pam_winbind.so对应NTLM。认证完成后，只有执行认证的模块自己知道用了哪种源，但不会把这个信息同步到内核或GLIBC的凭证结构里。
• 内核凭证的局限：credentials(7)里描述的凭证信息只包含UID、GID、权限位这类安全属性，完全不涉及认证来源的元数据。

可行的解决思路 #

如果一定要拿到认证源信息，只能从PAM层面入手：

• 修改PAM配置或自定义模块：让负责认证的PAM模块在认证成功后，把认证源记录到系统日志（比如syslog），或者通过自定义模块把信息写入进程能读取的地方（比如环境变量、临时文件）。
• 解析PAM认证日志：系统默认的PAM日志一般在/var/log/auth.log或/var/log/secure里，日志会记录使用的PAM模块名称，反向就能推断认证源。比如日志里出现pam_unix(sshd:session): session opened for user xxx就是本地认证，出现pam_krb5(sshd:auth): authentication succeeded就是Kerberos认证。
• 在程序里集成PAM会话查询：如果你的程序本身是通过PAM启动的，可以在PAM会话初始化阶段，尝试通过pam_get_item()获取模块上下文信息——但这得看具体PAM模块是否提供这类支持，不同模块实现差异很大，没有统一标准。

额外说明 #

• 像SUID程序或者直接通过fork/exec启动的进程，它们继承的是父进程的凭证，根本没经过PAM认证，这种情况本来就不存在“认证源”的说法。
• 有些服务（比如sshd、login）会在启动子进程时把认证方式通过环境变量传过去，但这是服务自己的行为，不是通用规则。

内容的提问来源于stack exchange，提问作者user13964273