数据丢失和权限被改

问题描述:

    湖南省委三期ZYJ桌面，在实施过程中，出现了形形色色的问题，其中代表性的问题是数据丢失和权限被改；

数据丢失：通过红盘或光盘导入的文件，在某种触发机制下，文件被删除，仅留下空文件夹，经回访了解，近期修改过的文件没有出现丢失；

权限被改：通过红盘或光盘导入的文件，在触发某种机制后，会把文件（包括文件夹、快捷方式）权限改为002，文件创建时间统一改成1970年1月1日上午8点整；

解决思路:

    由于问题重大，需要找出根源所在，通过日志只能看到有删除动作，但不能确定是什么原因造成的；而权限修改问题无日志可查，又很难进行复现，只能先在已经实施的机器上安装审计规则进行监控；同时，我们对数据丢失问题进行试验，通过不同删除动作来查看日志是否会记录具体的删除进程，对这两个问题进行逐一击破。

解决方法:

    由于需要定位具体的责任，同时证明不是系统问题，让用户放心的使用我们系统，我们通过正反验证方式进行索证，以下是对数据丢失进行验证：

反向验证：通过查找kern.log日志，发现slfilter（时代亿信后台监测程序）关键字会对删除动作进行监测，具体信息如图1-1所示：

图1-1

图1-1中my_inode_unlink表示删除；

继续往下查看，具体信息如图1-2所示：

图1-2

slfilter::[ETSMJBZUI1]格式频繁出现，发现此信息，我们立刻联系到时代亿信工程师，并了解到ETSMJBZUI1为密标进程，不会进行删除动作；然而，经过试验，我们通过shift+delete、桌面右键删除文件及终端使用rm删除文件，具体日志如图1-3、1-4所示：

图1-3 rm删除

图1-4 shift+delete/右键删除

使用shift+delete和桌面右键删除，slfilter监测为slfilter::[caja]，使用rm指令删除文件监测为slfilter::[rm]，通过试验，我们能确定[]中记录的为删除文件所使用的进程。由此，我们初步确定是密标进程在删除文件，排除了系统问题。

正向验证：由kern.log日志分析，初步确定是密标导致文件删除，因此，在北京基地，我们协同时代亿信工程师进行源码分析发现QClearCachethread函数会对早于系统7天之前的文件进行删除，以节省空间，不过该函数只会对ETC目录进行删除操作，然而，时代亿信工程师说查看的源码与HN省委所用源码有所差别，源码中增加了多并发操作功能，而该多并发功能存在健壮性问题，导致QClearCachethread函数中eetrust_path目录会随机变动而不是固定在用户的ETS子目录下，从而导致数据丢失。

综上所述，确定数据丢失为时代亿信密标导致。

由于，权限被改问题在添加审计规则后很难复现，不过在进行密标源码进行分析发现，源代码中有个函数，这个函数为了解决系统异常关闭导致密标文件没有及时写回或保存，对打开的临时文件进行保护而设置文件权限为002。在这个函数中也存在目录遍历，并且对et_path目录下对所有文件遍历，当发现该目录下如有文件修改时间比系统时间要早时，则会设置文件权限为Qfile::writeother，经查Qt文件接口上面的操作就是设置文件权限为002，由于当天查看的源码与HN省委使用的密标源码有差别，在对HN省委密标源码查看发现：相对于之前分析的源码，增加了多并发操作功能，而该多并发功能存在健壮性问题，导致该函数中et_path目录会随机变动而不是固定在用户的ETS子目录下；所以通过源码查看确定权限被改问题也为密标造成。

在问题查明后，我们给HN省委建议如下：

首先将HN省委中部署的系统中ETS密标软件全部卸载，避免再次发生，直到密标厂商修复并测试稳定后再部署；

同时密标厂商修好代码，对该函数中，在需要设置的文件权限操作时，增加对et_path目录的判定，当时用户的密标临时目录ETS时才触发，否则不执行。

问题总结:

    在经过HN省委三期内网终端替换项目，遇到形形色色的问题，在遇到问题后，我们不能立刻推卸责任，而应积极响应，及时对问题进行定位处理，让用户看清我们公司的服务态度以及研发实力，从而取消对我们系统的疑虑，安全放心的使用我们的系统。

    还有就是，在遇到紧急问题时，我们要第一时间收集日志，然后再根据实时情况进行问题处理，安抚用户的心情，等问题处理完，再协同研发对日志进行调查分析，定位问题所在，给用户一个满意的答复。