[0049] 图5详细说明了在截获时被截获读系统的这个过程。该例程在步骤500通过测 试一个会话（session)是否是导出的（unspooling)而开始。如果在步骤500的测试的结 果是否定的，该例程将继续，在步骤502分析原始系统调用。在步骤504中，原始系统调用 中的数据被保存。然后，在步骤506执行测试，以确定数据是否完整。如果在步骤506的测 试的结果为否定的，该例程周期的这个部分返回到步骤502,以从原始系统调用获得额外的 数据。然而，如果在步骤506的测试的结果是肯定的，这表明所有的数据是完整的，该例程 继续在步骤508实行数据变换。这种变换型的性质可能是相当不同的，例如，检查、编辑、改 变、限制、处理、更新，等等。对变换的性质和范围没有任何限制，这是一个已知的函数/运 算。实行变换后，该例程继续在步骤510将一个剩余计数器设置到一个改变的数据缓冲区 的大小。该例程然后继续在步骤512把该会话开始标记为导出的。控制然后在步骤514继 续，如果在步骤500的测试的结果是肯定的，也到达这个步骤。在步骤514中，复制将在原 始缓冲区安装（fit)的尽可能多的剩余的变化了的数据，并递减剩余计数器。然后在步骤 516进行测试，以确定剩余计数器是否为零。如果是这样的话，在步骤518将该会话去除导 出标记。该例程然后继续在步骤520返回到用户，在步骤516的测试的结果为否定的时，也 到达这个步骤。这就完成了对截获读系统调用情形的处理。
[0050] 在写系统调用的情况中，在调用原始系统调用之前，需要收集整个逻辑数据包，以 便能够实行变换。在这种情况下，调用系统调用的用户进程已经提供了一个具有要被发送 的数据的缓冲区。因为在数据被传输之前，需要对数据实行变换，所以，在能进行变换之前， 需要把原始数据包全部收集在一起。如上所述，数据包是有可能分散在多个系统调用中的。 也有这样的可能，即在实行变换后，新的包将不适合（fit)由用户进程提供的缓冲区。因 此，直到分析器确定整个数据包已被接收，该机制收集来自用户进程的数据，并从被截获系 统调用返回，如同该数据被成功传输一样。分析器然后实行变换，并将修改后的数据发送回 原始系统调用（即发送原始包的最后一部分的用户进程的调用）。如果新的包在调用过程 所提供的缓冲区内不适合，则调用该系统调用，必要时反复调用，而不返回到用户，直到变 换了的包的最后部分已经被发送。
[0051] 图6说明了在截获时写系统调用情况的详细处理流程。例程在步骤600通过保存 和分析数据而开始。在步骤602,进行测试，以确定数据是否完整。如果在步骤602中的测 试的结果是肯定的（数据完整），例程继续在步骤604去标记该会话为导入。例程继续在步 骤606实行一个数据变换，如上所述的那样。在步骤608,将剩余计数器设置为改变了的数 据缓冲区的大小。例程继续在步骤610复制将在原始缓冲区安装的尽可能多的剩余的变化 了的数据，并递减剩余计数器。步骤610后，例程返回到原始系统调用。这是步骤612。然 后在步骤614进行测试，以确定剩余计数器是否为零。如果不是，控制在步骤616返回到用 户。但是，如果剩余的计数器为零，则控制返回到用户616。如果在步骤602的测试的结果 是否定的，也到达步骤616,在这种情况下，在步骤618标记该会话标记为导入，然后返回到 用户。这就完成了对截获写系统调用情形的处理。
[0052] 换另一种方式来讲，在读的情况下，有一个被截获系统调用到实际系统调用的 (l:n)映射，其中将一个被截获系统调用转换为多个被调度的（dispatched)调用，直到完 整的数据集合被检索并且然后被返回（跨η个被截获呼叫）而不带对应的调度系统调用。 在写的情况下，有一个被截获系统调用到实际系统调用的（η:1)映射，其中η-1个被截获 调用没有对应的被调度的调用，第η个被截获调用包含数据集合的最后一部分，m个被调度 的调用在最后的被截获调用返回之前被执行。一旦数据被导入，就可以实行变换（包括不 变换）。作为一个例子，假设有一例简单的基于SQL的数据库查询"select*from employee where dept = 20"。如果向系统调用提交的数据被分割到含有字符串"seIect*from employee"和"where dept = 20"的两个缓冲区中，这两个字符串实际是同一查询的分部； 进一步假设变换包括一个规则，即 "Replace 'dept = 20' with 'dept = 21 ' when object ='employee' "（当 object = 'employee 时，用 'dept = 21 ' 替换 'dept = 20'）。另一种 可能的变换可能是"在试图访问部门"20"中的对象'employee'时放弃一个会话"（"Drop a session when attempting to access object 'employee' from dept. '20"，）。使用 本文的方法，可以对由用户应用程序提供的数据实行这些类型的变换，而没有由传递协议 (delivery protocol)插入的中断（breaks)或其他应用程序的限制。
[0053] 因此，如已经描述的那样，导入机制是用于被截获系统调用的时移装置，具有对发 送和接收的原始数据的可选的修改。正如在问题陈述中所描述的，为了在通过操作系统发 送和接收的数据上实行变换的目的而截获系统调用时，不能保证截获的数据量包含整个逻 辑包。例如，当截获数据库的TCP流量（traffic)时，单一的查询可能被拆分在多个读调用 中。根据本公开的方法，不是执行被截获系统调用到实际系统调用的1:1映射，在读期间， 被截获的数据被分析，原始系统调用按需要被重新调用，直到所有的数据都被读取；然后， 就能通过操作该完整的集合而实行一个变换，然后通过重新填充原始缓冲区而返回原始调 用者，可能跨多个系统调用。这使得能对调用被截获系统调用的用户进程透明地实行该变 换。
[0054] 此外，为了避免存储器限制，可以远程地处理数据和实行变换，从而使不同的数据 集合能与彼此关联。这种方法可以用在图3中的LDACS解决方案中。因此，举例来说，这种 数据关联的一个应用是保护主机数据库不受未经授权的访问。该变换被用来保护用标准的 访问控制难以保护或不可能保护的数据元素。例如，通过关联数据，用户的与数据库的整个 会话都可以通过从打开到关闭跟踪之而被观察。这个被授权的用户可能需要访问包含未予 授权查看或修改的数据子集的表。通过变换查询，受保护的数据可以得到自动保护（例如， 不用，select*from table'，而用，select*from table where···'）。然而，众所周知，关联 步骤和变换步骤是复杂的，需要保持会话期间中发生的情况的历史。这过于复杂，以致不能 向被截获系统调用插入直接插入码（in-line)，因此，该LDACS解决方案使得能够提供单独 的收集器/分析器，用于处理数据和把该信息反馈给系统调用。因为这个过程需要对用户 透明，因此，本公开的技术被用来"暂停"原始系统调用，直到处理完成。
[0055] 这里描述的机制的用途不止是数据库查询的编辑。这个机制可用于基于数据的内 容为数据设置防火墙、选择性地审计，等等。更一般来说，这种方法可用来方便需要在与系 统调用截获一起出现的数据的逻辑边界（而不是物理边界）上实行的任何变换一其中在实 行该变换之前需要导入数据（并且然后要在结束时导出结果）。
[0056] 本文的技术提供了许多优点。通过创建被截获系统调用到到实际系统调用的一对 多（复用的）映射，可以更有效地实行变换，即使被截获数据跨越一个以上的系统调用。在 I m映射中（读情况下），实际系统调用被按需要多次重新调用，然后再返回到用户空间。 特别地，该技术一直读到整个包被收集为止，然后实行该变换，然后将修改后的数据（包括 修改的包头）返回到用户空间。
[0057] 以上描述的缓冲机制的功能可以以内核修改的形式而实现，以独立方法的形式而 实现，或以它们的某种组合的形式而实现。在任一情况下，该变换都可以被实现为由处理器 执行的基于软件的功能，或者可以作为一个托管服务（包括通过S0AP/XML接口的网络服 务）而提供。本文所描述的特定的硬件和软件实现细节仅用于说明性目的，而不是用来限 制所描述的主题的范围。
[0058] 不作为对前述内容的限制，在其中可以使用本发明方法的代表性的LDACS解决方 案是 IjBM.⑩:Guardium(IBM、InfoSphere 和 Guardium 是国际商业机器公 司的注册商标）第8.0版。该解决方案包括一个可扩展的架构，包括收集器、聚合器和中央 管理设备，以及安装在数据库服务器上的软件开发