第二章：Improving On User Commands--17.记录删除文件操作

这个脚本是一个叫做wrappers脚本的完整类的示例。wrappers的基础思想是它们处于一个真实的Unix命令和用户之间，它在对真实的单个命令不可用的情况下，会给用户提供不同的、有效的功能。在这个脚本中，在不通知用户的情况下，用rm命令删除文件的操作实际上会被写入一个单独的log文件。(这段话真难理解，只有看到了wrappers的时候，或许才能理解。这个脚本的目的很简单，就是使用rm命令来删除文件时可以用本脚本文件作为一个替代，在使用本脚本时，如果不使用-s选项，则会记录这个删除操作到一个文本文件中。)

代码：

#!/bin/sh

# logrm.sh -- 记录所有的文件删除请求，除非使用-s选项

removelog="/home/epost/log/remove.log"    # 原书是写入/var/log目录下

if [ $# -eq 0 ]; then
echo "Usage: $(basename $0) [-s] list of directories." >&2
exit 1
fi

if [ "$1" = "-s" ]; then
# 不记录删除操作...不会写到log文件中
shift
else
echo "$(date): ${USER}: $@" >> $removelog
fi

/bin/rm "$@"

exit 0

运行脚本：
不只是给这个脚本一个叫做logrm的名字，一种典型导入一个wrappers程序的方式是重命名底层的程序，然后导入wrapper使用底层程序的旧名字。如果你选择这条路线，确保wrapper调用了最新的重命名后的文件，而不是它自身。比如，如果你把/bin/rm/重命名为/bin/rm.old，而你把这个脚本命名为/bin/rm，那最后几行脚本就需要改掉了，这样就会调用/bin/rm.old，而不是自身。你也可以使用一个alias，来让这个脚本封装一个标准的rm调用：
alias rm=logrm

不管你用哪种方法，你都会需要写然后执行到/var/log中，不过具体的配置还要看你的机器。

运行结果：
logrm.sh b.txt

分析脚本：
有一个潜在的文件所属权限问题。remove.log是可写的，此时一个用户可以清空它的内容，使用诸如cat /dev/null > /var/log/remove.log。或是remove.log是不可写的，此时脚本就不能记录删除操作。你可以设置用户权限，这样脚本就可以运行了，但这样也有两个问题。第一，这个主意真的很糟糕！永远不要在setuid后运行脚本。第二，如果这个原因还是不足，你有可能碰到一种状况，用户有权删除文件，而脚本没有，并且由于被setuid设置了过的uid位会被rm命令本身所继承，事情会变坏而当用户不能移动属于自己的文件时会很困惑，甚至是当他们带着问题核实、查看属于他们自己的文件时。还有2种别的情况需要注意。第一，如果你有一个ext2或ext3文件系统(可能是Linux)，你可以使用chattr命令将一个文件设置成一个很特别的只能从文件尾追加的模式，然后可以安全的将这个日志文件对所有人开放写权限。第二，你可以用logger命令把日志信息写到syslog中。比如这个脚本中记录的rm命令，用logger命令来表述的话就是：

logger -t logrm "${USER:-LOGNAME}: $*"