技术 · 实用指南
ld.so 提示“object from LD_PRELOAD cannot be preloaded”？先找注入者，再改库
这条警告只证明动态加载器拒绝了一个被请求的对象，并未说明是谁请求、为何失败。先保留命令，追踪全部预加载来源，比较可执行文件与对象的 ELF 身份，再只修改真正负责的配置。
该信息由动态加载器在目标程序完全启动前输出，表示某个附加对象被请求却被忽略；它不能证明所有共享库都缺失，也不能证明前台程序创建了请求。
建立“所有者到对象”的证据账本：先确认请求来自进程环境、启动器、服务还是 /etc/ld.so.preload，再依据路径、ELF 身份、映射和安全执行证据分流。
1. 固定准确警告与执行上下文
保存完整 ld.so 行、对象标记、括号内原因、准确命令、可执行路径、用户身份、工作目录与时间。“cannot open”“failed to map”和安全模式清除不是同一结论。
只有在安全时才复现一次，并记录警告来自交互 shell、包装脚本、服务、容器入口还是特权程序。不要先重装尚未证明归属的库。
2. 找出全部预加载所有者
检查进程环境、shell 启动文件、包装脚本、服务 Environment/EnvironmentFile 与容器配置；单独检查 /etc/ld.so.preload，它会在环境变量之外全局生效。
若当前 shell 中 unset LD_PRELOAD 后警告仍在，说明还有其他所有者，而不是加载器一定损坏。编辑前保存每个值及来源。
3. 区分路径、访问与对象身份
按加载器实际解析方式核对对象标记，并记录存在性、类型、所有权、权限与挂载上下文。目录、断链、不可读文件或被空格/冒号拆分的标记都不是有效对象。
分别用 file 和 readelf 检查目标可执行文件与对象，比较 ELF 位数、字节序、OS/ABI 与机器字段；不要为了检查而执行不受信对象。
4. 分开映射、重定位与安全执行
路径与 ELF 身份匹配后，在同一非特权测试中收集加载器诊断，查段映射、依赖、重定位、符号或版本失败，不要都归为“文件缺失”。
set-user-ID、set-group-ID 或带 capabilities 的程序会进入安全执行模式并限制 LD_PRELOAD；不要通过削弱权限或把任意对象复制进可信目录来绕过。
5. 修复所有者并验证
只在已证明的 shell 配置、包装器、服务、容器定义或 /etc/ld.so.preload 中删除或修正；只有证明包拥有目标对象且 ABI 匹配后才安装或恢复。
先用同一可执行文件做无预加载测试，再在确需注入时测试已验证对象；警告消失、对象按预期加载或缺席、功能正确且其他进程不受影响才算通过。
