1. 项目概述与漏洞背景CVE-2022-0847也就是大家常说的“脏管道”Dirty Pipe漏洞是2022年初在Linux内核中发现的一个影响范围极广的本地权限提升漏洞。我第一次在内部安全通告里看到这个漏洞编号时心里就咯噔一下因为它的描述太“经典”了一个位于内核管道pipe和页面缓存page cache交互逻辑中的缺陷允许低权限进程向任意只读文件写入数据。简单来说它能让一个普通用户在特定条件下修改系统里那些他原本没权限碰的文件比如/etc/passwd或者/etc/shadow从而获得root权限。这个漏洞的CVSS评分高达7.8属于高危级别更关键的是它影响从Linux内核5.8版本开始一直到5.16.11、5.15.25、5.10.102这些修复版本之前的所有主流发行版像Ubuntu 20.04/21.10、Fedora、Debian等都在影响之列。这个漏洞的发现和披露过程也很有意思它最初并不是通过常规的安全审计发现的而是源于一个用户提交的关于文件损坏的技术支持工单。开发者Max Kellermann在排查这个看似普通的文件损坏问题时一路深挖最终定位到了内核深处的一个逻辑错误并将其转化成了一个稳定可靠的提权利用。这种从“小问题”里挖出“大漏洞”的经历对我们做安全研究或运维的人来说特别有启发很多严重的安全隐患最初的表现形式可能都非常不起眼。漏洞公开后网上很快就出现了PoC概念验证利用代码比如GitHub上Al1ex维护的那个仓库代码非常简洁核心逻辑只有几十行C语言但威力巨大。接下来我就结合这个公开的PoC带大家一步步拆解这个漏洞的原理、环境搭建、利用过程以及最重要的——修复和缓解措施。无论你是想了解漏洞机理的安全爱好者还是负责系统安全的运维工程师这篇文章都能给你一份清晰的“操作指南”和“避坑手册”。2. 漏洞原理深度解析为什么管道会变“脏”要理解CVE-2022-0847我们得先抛开那些复杂的内核数据结构用更形象的比喻来思考。你可以把Linux内核中管理文件数据的“页面缓存”Page Cache想象成一个巨大的、共享的图书馆。当一个进程读取一个文件时内核并不是每次都傻傻地去慢吞吞的磁盘上找而是会把文件内容先加载到内存里这个“图书馆”中这个内存中的副本就是页面缓存。之后其他进程再读同一个文件只要这个副本还在内存里就可以直接从“图书馆”里借阅速度飞快。所有进程看到的都是同一个“图书馆藏书”缓存页面这保证了数据的一致性。而“管道”Pipe则是进程间通信的一种基本方式它就像连接两个进程的一条水管。进程A往水管的一端写数据进程B从另一端读数据。内核为了高效处理这种数据流在实现管道时引入了一个优化当进程通过splice()系统调用把文件数据“ splice ”可以理解为“接入”或“引流”到管道时内核并不会老老实实地把文件数据从页面缓存拷贝一份到管道缓冲区而是玩了一个“花招”——它让管道的缓冲区直接指向页面缓存里对应的那个内存页面。这是一种“零拷贝”技术目的是减少不必要的数据复制提升性能。这里就引入了第一个关键角色PIPE_BUF_FLAG_CAN_MERGE这个标志位。这个标志位存在于管道缓冲区的一个内部结构里它的本意是如果一个缓冲区有这个标志那么后续写入这个缓冲区的数据如果可以跟现有数据合并就允许合并而不是分配新的缓冲区。这本来是为了优化连续的小规模写入操作的。漏洞的根子就出在这个标志位的管理上。在splice()操作完成后内核错误地没有清除这个PIPE_BUF_FLAG_CAN_MERGE标志位。于是这个管道缓冲区就带着一个“我可以被合并”的标签同时却又直接指向了属于页面缓存那个共享图书馆的珍贵书页。现在最致命的一步来了。如果一个低权限进程在通过splice()“借用”了某个只读文件比如/etc/passwd的缓存页面到自己的管道之后再调用write()系统调用向这个管道的同一位置写入数据会发生什么由于那个CAN_MERGE标志还在内核会认为“哦这个缓冲区允许合并写入而且它现在指向的是页面缓存那我就直接把用户要写的新数据合并写到它指向的那个内存页面里好了。” 这一写就直接写回了共享的页面缓存也就是说进程绕过了文件系统的所有权限检查因为操作对象是管道而管道写入通常不需要文件权限直接篡改了内核中为所有进程共享的文件数据缓存。当下一次任何进程包括高权限的进程读取这个文件或者内核决定把脏的缓存页面写回磁盘时被篡改的内容就会被同步到磁盘上的原始文件中。至此一个普通用户就完成了一次对只读文件的非法写入。注意这个漏洞利用有几个关键前提1目标文件必须至少有一个字节是可读的这样才能通过splice建立关联2需要能够创建管道并进行splice和write操作3对目标文件的写入位置有精确的偏移要求。公开的PoC通常选择/etc/passwd是因为它全局可读且在其中插入一个UID为0的用户条目就能直接提权路径依赖最短。2.1 核心数据结构与代码逻辑透视如果我们再深入一点看看内核源码以受影响版本为例就能更清楚地看到问题所在。关键函数是kernel/pipe.c中的pipe_write()和splice相关的逻辑。当splice来自文件时会调用copy_page_to_iter_pipe之类的函数在这个过程中pipe_buffer结构的flags字段被设置了PIPE_BUF_FLAG_CAN_MERGE但后续没有在适当的时机被清理。在正常的管道写入流程pipe_write()中有一个判断逻辑如果当前要写入的缓冲区pipe_buffer的flags包含PIPE_BUF_FLAG_CAN_MERGE并且写入位置与该缓冲区现有数据的末尾连续那么内核就会尝试在这个现有缓冲区上追加数据即“合并”而不是分配新缓冲区。问题就在于经过splice操作后这个缓冲区指向的是文件缓存页page cache而合并写入操作会直接修改这个共享页的内容完全忽略了该页背后文件的只读属性、权限位inode的i_writecount等以及任何其他安全策略。// 以下为示意性伪代码说明漏洞点 static ssize_t pipe_write(struct kiocb *iocb, struct iov_iter *from) { struct pipe_inode_info *pipe iocb-ki_filp-private_data; // ... 其他逻辑 ... for (;;) { struct pipe_buffer *buf pipe-bufs[(pipe-curbuf pipe-nrbufs) % pipe-buffers]; // 关键判断如果缓冲区可合并且写入是连续的 if (buf-flags PIPE_BUF_FLAG_CAN_MERGE offset len PAGE_SIZE) { // 那么就直接向buf-page指向的内存页面写入数据 char *addr kmap_atomic(buf-page); memcpy(addr offset, data_from_user, len); kunmap_atomic(addr); // 缓冲区内容被修改但因为它指向的是page cache所以文件缓存被污染了 // 没有任何针对目标文件的权限检查在这里发生 break; } // ... 否则分配新缓冲区 ... } // ... 后续逻辑 ... }这个设计初衷是为了性能的“合并写入”特性当遇到了“管道缓冲区直接引用文件缓存页”这个优化时就产生了化学反应酿成了权限绕过的大祸。内核的修复方案也直截了当在splice操作将文件数据接入管道后立即清除相关缓冲区的PIPE_BUF_FLAG_CAN_MERGE标志位从根本上杜绝了向这些“借来的”页面执行合并写入的可能。3. 漏洞复现环境搭建与准备理论讲得再多不如亲手实践一遍来得深刻。复现漏洞不仅能验证原理更能让你对漏洞的触发条件、成功率和潜在风险有直观感受。不过我必须强调所有复现操作都必须在你自己拥有完全控制权的、隔离的测试环境如虚拟机中进行严禁在生产环境或任何他人的系统上尝试3.1 测试环境配置我选择Ubuntu 20.04.3 LTS作为测试系统因为它是一个受漏洞影响的、非常普遍的发行版。首先我们需要一个存在漏洞的内核版本。在2022年3月补丁发布前安装的Ubuntu 20.04其内核版本通常在5.4到5.13之间都处于影响范围内。你可以通过uname -r命令查看。uname -r # 输出可能类似5.11.0-46-generic为了确保环境纯净且可任意破坏我强烈建议使用虚拟机。VirtualBox或VMware Workstation Player都是免费好用的选择。在虚拟机中安装好Ubuntu 20.04后第一件事是创建快照。这样无论我们后面把系统玩成什么样都能一键恢复到干净状态。接下来我们需要一个非root的普通用户账号来模拟攻击者。如果安装系统时只创建了root用户需要手动添加sudo adduser testuser # 按照提示设置密码等信息然后切换到这个普通用户环境。后续的所有漏洞利用编译和执行都将在这个testuser的权限下进行。su - testuser whoami # 输出应为 testuser id # 输出应显示uid1001(testuser) gid1001(testuser) groups1001(testuser)没有sudo权限。3.2 工具与依赖安装复现过程主要依赖GCC编译器和一些基本的系统工具。在Ubuntu上它们通常已经预装但为了保险起见可以更新并安装build-essential包。# 在普通用户下需要使用sudo这里我们先切换回root或具有sudo权限的初始用户进行操作 exit # 退出testuser回到之前的用户假设有sudo权限 sudo apt update sudo apt install -y build-essential # 再次切换到testuser su - testuser现在准备漏洞利用代码。我们将使用GitHub上广泛流传的那个简洁版PoC。在你的testuser家目录下创建一个工作目录。cd ~ mkdir dirtypipe-test cd dirtypipe-test然后创建一个名为dirtypipe.c的文件并将PoC代码粘贴进去。代码的核心逻辑我已经在原理部分解释过它主要做以下几件事打开目标文件如/etc/passwd获取文件描述符。创建一个管道。使用splice()将目标文件的一小部分内容“引流”到管道这使得管道缓冲区指向了文件的页面缓存并且错误地保留了CAN_MERGE标志。计算好偏移量向管道写入精心构造的数据例如在/etc/passwd中插入一个密码字段为空的root级别用户。利用成功的话目标文件在磁盘上的内容就被篡改了。由于代码较长这里不全文贴出你可以从可靠的来源如Al1ex的GitHub仓库获取。获取后使用GCC编译它gcc dirtypipe.c -o dirtypipe如果编译成功你会得到一个名为dirtypipe的可执行文件。在运行前务必备份即将被篡改的关键文件这是最重要的操作纪律。# 备份/etc/passwd这是我们的主要测试目标 sudo cp /etc/passwd /tmp/passwd.bak # 确认备份成功 ls -l /tmp/passwd.bak实操心得备份这一步千万不能省。我见过有人复现时忘了备份把测试机的/etc/passwd搞乱了导致连root都登录不了最后只能重装系统。另外除了/etc/passwd也可以尝试其他只读文件如/etc/shadow需要先调整权限为可读或某些SUID程序但/etc/passwd是最直观、影响最可控的选择。记住我们是在学习研究不是搞破坏一切操作要以能快速恢复为前提。4. 漏洞利用过程逐步拆解环境准备好了代码编译好了备份也做了现在让我们来实际运行这个漏洞利用程序看看它是如何一步步将普通用户权限提升至root的。4.1 执行漏洞利用程序我们的PoC程序通常需要两个参数目标文件路径和要写入的偏移量以及要写入的内容有些实现是硬编码在代码里的。以常见的修改/etc/passwd为例我们想在文件末尾追加一个UID为0即root权限的用户。首先查看一下原始/etc/passwd文件的内容和大小。tail -5 /etc/passwd wc -l /etc/passwd # 假设输出是45行那么文件末尾的偏移量从0开始计字节大约在...但更稳妥的方法是让程序自己计算。很多公开的PoC比如Al1ex仓库里的exp.c其逻辑是先splice文件开头的第一个页面4096字节然后向管道偏移量1处写入数据。因为管道缓冲区继承了文件页面缓存向管道偏移1写入就相当于向文件偏移1写入。它会覆盖文件开头的部分内容。为了提权它选择覆盖/etc/passwd的第一行root用户行或者找一个合适的位置插入。但更常见的、破坏性更小的做法是在文件末尾添加一个新用户。我们需要根据PoC的具体实现来调整。假设我们使用的PoC程序dirtypipe接受参数./dirtypipe 目标文件 偏移量 要写入的字符串。我们想在/etc/passwd文件末尾添加一行首先要知道文件末尾的字节偏移量。# 获取文件总字节数 filesize$(stat -c%s /etc/passwd) echo $filesize # 假设输出 2653那么偏移量就是2653。我们要写入的字符串是一个符合/etc/passwd格式的用户行例如ootz::0:0::/root:/bin/bash。注意这里用户名为ootz密码字段为空两个冒号::这意味着该用户无需密码即可登录且UID和GID都是0root。这是一个极度危险的后门账户仅在测试环境使用完成后必须立即删除现在执行漏洞利用./dirtypipe /etc/passwd 2653 $ootz::0:0::/root:/bin/bash\n注意$...\n的语法是为了确保字符串末尾包含换行符这样新添加的行才是独立的。不同的PoC实现可能对参数格式有不同要求请务必阅读你所用代码的注释或逻辑。执行后程序如果没有报错并正常退出就说明利用过程从程序角度看是成功的。但它是否真的改变了磁盘上的文件呢我们需要验证。4.2 验证利用结果验证分两步首先检查内存中的缓存是否被改变即当前系统看到的文件内容然后确认更改是否已持久化到磁盘。# 查看/etc/passwd文件的最后几行 tail -5 /etc/passwd你应该能看到新添加的ootz::0:0::/root:/bin/bash这一行。这说明页面缓存已经被成功篡改。任何读取该文件的进程现在都会看到这个新用户。接下来触发内核将脏页面写回磁盘。最简单的方法是强制同步一下sync # 或者 cat /etc/passwd /dev/null 并等待一下但sync更直接。现在磁盘上的文件应该已经被修改了。我们可以用cat命令再次确认或者使用hexdump查看文件末尾的原始字节。# 用su命令尝试切换到我们创建的ootz用户 su ootz # 执行后应该不需要输入密码直接获得root shell提示符#。 whoami # 输出应为 root id # 输出应显示 uid0(root) gid0(root) groups0(root)如果su ootz成功并且whoami显示为root那么恭喜你也“恭喜”这个系统本地提权漏洞利用成功了一个普通的testuser账户通过利用内核漏洞获得了系统的最高控制权。4.3 利用后的清理与恢复实验成功后务必立即清理现场恢复系统原状。这是我们作为负责任的测试者必须做的。删除后门账户首先退出root shell回到原来的testuser终端。exit # 从ootz的root shell退出 # 现在我们应该还在testuser的bash下由于我们已经是通过漏洞获得了任意文件写入能力我们可以直接编辑/etc/passwd文件来删除添加的行。但更安全、更规范的做法是使用sudo和vipw命令如果你当前的用户还有sudo权限的话或者直接使用备份文件恢复。# 方法一使用备份恢复最推荐最干净 exit # 退出testuser回到有sudo权限的用户 sudo cp /tmp/passwd.bak /etc/passwd # 方法二手动编辑如果备份不可用 # sudo sed -i /^ootz:/d /etc/passwd验证恢复结果再次切换回testuser尝试用su ootz登录此时应该提示“未知的用户 ootz”证明后门已清除。su - testuser su ootz # 应提示su: user ootz does not exist恢复虚拟机快照这是最彻底的清理方式。关闭虚拟机恢复到实验开始前创建的干净快照。这样所有实验痕迹都会被抹除。重要注意事项这个漏洞利用的成功率并非100%它依赖于内存布局和时机。有时可能需要多次运行PoC才能成功。此外一些现代发行版或打了补丁的内核可能包含了其他缓解措施如/etc/passwd文件具有不可变属性immutable这可能会阻止利用。我们的复现环境是精心挑选的未打补丁的旧内核以确保成功。在真实环境中千万不要抱有侥幸心理认为利用不成功系统就是安全的。只要内核版本在影响范围内就必须立即修复。5. 漏洞影响范围与修复方案CVE-2022-0847的影响可以说是“又广又深”。说它广是因为Linux内核作为现代计算设施的基石从服务器、桌面系统到嵌入式设备和安卓手机都在其影响范围内。任何运行Linux内核5.8及以上版本且未及时更新到修复版本的系统都存在风险。说它深是因为这是一个本地权限提升漏洞攻击者需要先获得一个本地低权限用户账号例如通过钓鱼邮件、其他应用漏洞等才能利用此漏洞。但一旦利用成功攻击者就能获得root权限完全控制整个系统可以安装后门、窃取数据、横向移动危害极大。5.1 受影响版本与产品根据漏洞发现者及各大发行版的安全公告受影响的核心范围是Linux内核版本 5.8 5.16.11 5.15.25 5.10.102。主流发行版Ubuntu: 20.04 LTS (Focal Fossa), 21.10 (Impish Indri) 等具体取决于其搭载的内核版本。Debian: 旧稳定版bullseye及测试版bookworm中受影响的内核包。Fedora, CentOS Stream, RHEL: 相应版本的内核包。Android该漏洞同样影响Android系统因为其内核基于Linux。谷歌在漏洞披露后很快将修复补丁合并进了Android内核。下表整理了部分发行版的受影响状态及修复版本发行版受影响版本示例已修复的内核版本修复建议Ubuntu20.04 LTS (内核 5.4, 5.8, 5.11等)linux-image-5.4.0-100.113 及更高sudo apt update sudo apt upgrade linux-image-genericDebianbullseye (内核 5.10.x)5.10.106-1 及更高sudo apt update sudo apt upgrade linux-image-amd64Fedora34, 35 (内核 5.14, 5.15)5.16.11 或发行版向后移植的补丁版本sudo dnf update kernelRHEL/CentOS8.x, 9.x (取决于内核版本)通过后续安全更新提供修复sudo yum update kernel5.2 官方修复与升级指南修复此漏洞的唯一彻底方法是更新内核。各Linux发行版在漏洞公开后都迅速发布了安全更新。对于系统管理员和个人用户来说操作流程是标准的检查当前内核版本uname -r更新软件包列表sudo apt update(Debian/Ubuntu) 或sudo yum check-update/sudo dnf check-update(RHEL/Fedora)。升级内核包Debian/Ubuntu:sudo apt upgrade linux-image-generic或sudo apt full-upgradeRHEL/CentOS 7:sudo yum update kernelRHEL/CentOS 8/Fedora:sudo dnf update kernel重启系统内核更新需要重启才能生效。sudo reboot验证重启后再次运行uname -r确认内核版本已升级到修复版本。除了更新内核对于无法立即重启的关键服务器可以考虑以下临时缓解措施效果有限不能替代修复限制用户能力严格控制系统用户账户遵循最小权限原则。避免不必要的用户拥有shell访问权限。使用安全模块如SELinux或AppArmor可以为关键进程和文件提供额外的强制访问控制增加利用难度。文件系统属性对极其重要的只读文件如/etc/passwd,/etc/shadow设置immutable属性使用chattr i命令。但这可能会影响系统正常管理操作需谨慎评估。运维心得面对此类内核级高危漏洞我的经验是“宁严勿松”。在漏洞细节公开的初期利用代码可能迅速扩散。对于互联网暴露的服务器从漏洞公开到被大规模扫描利用时间窗口可能只有几个小时到几天。因此必须建立快速的安全补丁响应机制。对于开发测试环境可以立即更新。对于生产环境应在评估补丁兼容性后尽快安排在维护窗口内进行更新。同时要利用监控系统关注异常提权行为如非特权用户突然执行su或sudo。6. 漏洞排查与深度分析技巧复现漏洞之后我们不应该仅仅停留在“能运行PoC”的层面。作为安全从业者或系统管理员我们需要掌握如何检测系统是否存在此漏洞、如何分析漏洞利用的痕迹以及如何从这次事件中汲取更深的教训。6.1 系统漏洞检测方法如何判断一个正在运行的系统是否受CVE-2022-0847影响最准确的方法是核对内核版本。# 方法1直接查看内核版本 uname -r # 将输出与受影响版本范围对比5.8, 且小于 5.16.11/5.15.25/5.10.102 # 方法2使用漏洞扫描工具 # 例如使用trivy一个容器/系统漏洞扫描器 # 首先安装trivy然后扫描本地系统 # trivy fs --severity HIGH,CRITICAL / # 专业的漏洞管理平台或安全补丁管理系统也会标记此CVE。然而内核版本号只是一个初步判断。因为有些发行版会向后移植安全补丁。也就是说一个版本号看起来在受影响范围内的内核可能已经包含了修复该漏洞的补丁。最可靠的检测方法是检查内核是否包含修复该漏洞的特定补丁。这可以通过查看内核的配置或编译时注入的版本信息来判断但对普通用户来说比较复杂。一个更实用的、非侵入性的检测方法是尝试编译并运行一个无害的PoC测试程序。这个测试程序不进行任何实际的破坏性写入而是尝试触发漏洞机制并通过检查返回值或某个可控的副作用来判断漏洞是否存在。例如可以尝试向一个临时创建的、只有自己可读的文件进行“脏管道”写入然后读取验证。如果写入成功则证明漏洞存在。再次强调此测试必须在隔离环境进行并且要确保测试文件路径和操作不会影响系统。6.2 入侵痕迹分析与取证假设假设一个系统被怀疑通过脏管道漏洞入侵了作为应急响应人员你应该从哪里入手这个漏洞利用留下的痕迹相对较少但并非无迹可寻。文件完整性检查这是最直接的线索。检查/etc/passwd、/etc/shadow、/etc/sudoers等关键文件的完整性。使用ls -l查看修改时间使用cat或vim查看是否有异常新增的用户特别是UID为0的非root用户名。与已知的干净备份进行diff对比。# 检查/etc/passwd中UID为0的用户 awk -F: ($3 0) {print $1} /etc/passwd # 正常情况下应该只有root。如果出现其他用户名就是重大嫌疑。进程与命令历史漏洞利用过程会执行编译gcc和运行./dirtypipe操作。检查当前用户的.bash_history文件以及系统的auth.log、secure日志记录su、sudo命令。攻击者可能会清理历史记录但有时会遗漏。# 查看当前用户的历史命令攻击者可能已清除 history # 查看系统认证日志寻找可疑的su或登录事件 sudo grep -i \su\\|ootz\ /var/log/auth.log内核日志漏洞利用本身可能不会在内核日志dmesg或/var/log/kern.log中留下直接报错。但是如果利用导致系统不稳定或触发了其他保护机制如页错误可能会有相关记录。时间线分析对比关键文件如/etc/passwd的修改时间mtime、漏洞公开时间、以及系统中其他异常事件如异常网络连接、新进程启动的时间可以构建攻击时间线。内存取证在高级取证中可以获取系统内存镜像然后使用Volatility等工具搜索与管道、页面缓存或特定利用代码相关的内存结构。但这需要专业知识和工具。排查技巧实录在实际排查中我遇到过一个案例攻击者利用脏管道漏洞添加了一个隐藏用户用户名末尾带空格如root在/etc/passwd中肉眼难以察觉。这时使用cat -A /etc/passwd命令显示所有字符包括空格和行尾符或者用脚本严格按字段解析就非常有用。另外攻击者可能会在利用后立即将/etc/passwd的修改时间改回原值通过touch -r命令以躲避基于mtime的检查。因此结合文件内容校验如SHA256哈希和完整性监控系统如AIDE, Tripwire才是更可靠的防御。6.3 从漏洞中学到的安全启示CVE-2022-0847不仅仅是一个需要打补丁的漏洞它更是一堂生动的安全课。安全与性能的永恒博弈漏洞根源在于内核为了追求“零拷贝”带来的性能提升牺牲了严格的安全边界检查。这提醒我们任何性能优化都必须以不破坏基本的安全隔离为前提。在代码审查中对涉及权限边界和共享资源的优化要格外警惕。漏洞的间接发现路径这个漏洞最初是因“文件损坏”这种非安全事件而被发现的。这告诉我们安全团队需要与运维、开发团队紧密合作关注所有类型的异常因为它们都可能是更深层次安全漏洞的冰山一角。最小权限原则的失效在漏洞面前即使严格遵守最小权限原则普通用户无写权限也无法阻止攻击者。这凸显了纵深防御的重要性不能只依赖单一防线如文件权限还需要结合内核安全模块、容器隔离、系统调用过滤seccomp等多层防护。开源软件供应链安全Linux内核的漏洞影响全球。作为用户我们需要及时关注上游安全公告建立快速的补丁应用流程。作为开发者则要参与到开源社区中关注并贡献代码安全。对于个人开发者和运维人员我个人的体会是保持系统更新是最廉价也是最有效的安全手段之一。同时要培养“怀疑一切”的安全意识即使是像文件权限这样基础的安全机制在复杂的软件系统中也可能因为一个底层bug而失效。定期进行安全审计、使用漏洞扫描工具、并对关键系统进行完整性监控应该成为运维工作中的标准动作。这个漏洞的复现过程就像一次攻防演练让我们更深刻地理解了攻击者的思维和手段从而能更好地构建我们的防御体系。