1.服务器环境以及配置
4.19.90-23.8.v2101.ky10.aarch64
【OS镜像版本】
0518-server
2.问题现象描述
服务器通过vncserver@:1.service服务启动的vnc服务后，普通用户用vnc连接时，锁屏后，然后输入登陆密码会报密码错误，无法登陆进去。在使用loginctl unlock-session id 测试、点击开始菜单锁屏或者命令ukui-screensaver-dialog --lock锁屏后，输密码登陆都会报错。如图1
图 1
服务器版本如图2
图 2
3.问题分析
在锁屏前，我们查看ukui-screensaver进程如图3
图 3
锁屏后，发现多出来两个ukui-screensaver-dialog --lock的进程。后续可以考虑针对这两个多出来的进程做排查。如图4
图 4
输入正确密码后，我们查看 /var/log/secure日志，发现报错：pam_faillock(ukui-screensaver-qt:auth): Configuration file missing or broken，可知，锁屏登录验证的时候，锁屏程序在调用faillock模块时候出现了问题，提示的是文件丢失或者损坏。如图5
图 5
rpm -Va查看文件修改记录，可以看到/etc/pam.d/下面的文件被修改过，如图6
图 6
将正常机器的/etc/pam.d/下面的文件全部拷贝过来覆盖有问题机器上的文件，问题依然存在，如图7
图 7
比较faillock相关的文件md5值，未见异常。如图8
图 8
添加audit规则，监控在vnc登录的时候，有哪些进程用到了pam_faillock模块。如图9
图 9
然后我们执行登录操作后，在audit日志中可以看到使用pam_faillock模块的进程号，正好是只有/usr/bin/ukui-screensaver-dialog --lock，如图10、图11
图 10
图 11
我们在一边执行登录操作的时候，一边用strace跟踪/usr/bin/ukui-screensaver-dialog --lock的系统调用，发现有/etc/security/faillock.conf的权限不够的报错。如图12
图 12
查看/etc/security/下面文件的权限，全部被改成了700，如图13
图 13
将文件权限恢复，如图14
图 14
发现问题依然存在，于是继续使用strace跟踪，发现还是提示的权限不够，查看 /etc/security目录权限发现也被改成了700，如图15、图16
图 15
图 16
最后，将/etc/security目录权限恢复正常后，可以正常登录进去系统。
4.问题分析结果
该问题出现的根本原因为/etc/security目录以及该目录下面的文件权限全被被改成了700，导致其他非root用户对该目录以及目录下的文件没有读的权限，从而登录失败。
5.解决方案
将 /etc/security目录以及该目录下面的文件权限恢复正常即可。
6.后续计划与建议
部署第三方应用的时候，注意主要系统配置文件权限不能被修改。
