ld_preload仅对当前进程及其子进程生效，无法全局设置；错误地全局配置会导致基础命令崩溃，安全做法是临时前置设置或通过wrapper脚本、systemd限定作用范围。
LD_PRELOAD 只对当前进程生效，不能“全局设置”
LD_PRELOAD 不是系统级配置，它只影响设置了该变量的单个进程及其子进程。你无法通过修改 /etc/profile 或系统级配置让所有程序默认加载某个 .so —— 那样会导致 apt、ls、bash 等基础命令崩溃，就像你看到的 ERROR: ld.so: object './libadd_c.so' from LD_PRELOAD cannot be preloaded 报错那样。
常见错误现象：
- 把
export LD_PRELOAD=/path/to/lib.so写进~/.bashrc后，终端一打开就报错，apt update直接失败 - 用
sudo运行命令时，LD_PRELOAD 失效（因为 sudo 默认不继承环境变量） - 写错路径或库 ABI 不匹配，导致程序启动即 segfault，连错误信息都看不到
临时设置：只在需要时加，加完立刻验证
最安全的做法是只在运行目标程序前那一行设置，不污染 shell 环境。
- 直接在命令前加：
LD_PRELOAD=./myhook.so ./target_program - 如果要带参数，确保等号后**不能有空格**：
LD_PRELOAD=/tmp/liblog.so strace -e trace=openat ls - 验证是否生效：运行后立即执行
cat /proc/$(pidof target_program)/maps | grep myhook，能看到内存映射说明加载成功 - 若提示
cannot be preloaded (wrong ELF class)，说明 32/64 位不匹配；若提示undefined symbol，说明你的.so没链接-ldl或没导出符号
永久设置必须限定作用范围，否则就是自毁式操作
真要“永久”，必须绑定到具体命令或用户场景，而不是无差别注入整个 shell。
- 封装成 wrapper 脚本：
#!/bin/bash<br>exec LD_PRELOAD=/opt/mytool/libintercept.so /usr/bin/original_cmd "$@"
然后chmod +x /usr/local/bin/mycmd，用mycmd替代原命令 - 对特定服务设 systemd 环境：编辑
/etc/systemd/system/myapp.service，在[Service]下加一行：Environment=LD_PRELOAD=/usr/lib/myapp/preload.so，再systemctl daemon-reload && systemctl restart myapp - 绝对不要在
~/.bashrc里写export LD_PRELOAD=...—— 即使加了if [ "$TERM" = "xterm-256color" ]这类判断也不保险，因为很多后台任务、cron、sudo 子 shell 都会意外触发
卸载 LD_PRELOAD 的真正方法不是 unset，而是避免继承
很多人以为 unset LD_PRELOAD 就万事大吉，但问题往往出在子进程继承了父进程的环境。真正有效的“卸载”是切断传播链。
- 检查是否被父进程注入：
env | grep LD_PRELOAD，如果为空但子进程仍有，说明父 shell 或 systemd 已设好 - 用
env -i bash启动干净 shell，再测试，确认是否环境残留 - 排查
/etc/ld.so.preload—— 这个文件比环境变量更隐蔽、影响全系统，用cat /etc/ld.so.preload查看，非空则立即清空并sudo ldconfig - 某些恶意软件会改写
/etc/profile.d/*.sh，检查是否有可疑export LD_PRELOAD行
malloc、open、getenv 这些底层函数。哪怕你只想 hook printf，如果库中没正确处理 RTLD_NEXT 回调或初始化顺序错乱，整个进程就可能卡死或静默失效 —— 它不会报错，只会行为异常。
