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.后续计划与建议

部署第三方应用的时候，注意主要系统配置文件权限不能被修改。