技术学习方面的东西，需要自己不断的区总结和复盘，把知识转化为自己的
也要理论作为经验的支柱，来使它更加健壮
问题现象
用户执行 crontab 的时候，报错permission deny 的错误，具体错误内容
crontab -e
/var/spool/cron/crontabs/admin: Permission denied排查过程
权限检查
首先既然报错是 permission deny 所以想到的果断就是先检查bin文件的权限配置问题，发现crontad 的权限是 777（rwxrwxrwx），看起来执行完全没有问题。
使用 root 的用户来进行操作，发现root用户是可以执行没有问题。
检查/var/spool/cron/crontabs/admin 的文件的权限，用户组以及用户也都是正常的
深入排错
检查用户的sudoer 的权限看是否有限制使用 bin 的权限，但是实际上这个permission deny 不是在open crontab时产生的错误。
所以遇事不决，来进行堆栈分析，在Clib调用的层面上来进行分析进行定位，使用 strace来看看执行时候的栈信息来定位问题，使用命令strace crontab -l来看看
会在打印的函数调用里面有这样的一条，这里的文件就是 crontab 配置的内容，
chdir("/var/spool/cron") = 0
#...
write(2, "crontabs/rms/: fopen: Permission"..., 40crontabs/rms/: fopen: Permission denied
) = 40可以看到在打开这个文件时候就报错了，拼接起来看看
➜ ~ cat /var/spool/cron/crontabs/rms
cat: /var/spool/cron/crontabs/rms: Permission denied定位问题
在了解Cron的工作方式之后，想到了Crond 的一个特性，也就是每个用户维护自身的一个 crond 的配置，所以在执行权限上是需要有区分。所以在这里的crontabs 的文件夹是 t 位，也就是意味着，用户可以对这个目录来进行文件的存取，但是只能操作自己拥有的文件和目录。
cd /var/spool/cron/
ll crontabs
drwx-wx--T 2 root crontab 3 7月 4 15:16 crontabs/另外，如果直接访问这个文件，会被上层的文件夹的权限策略所deny掉，所以在执行crontab 的时候需要更高的权限，
➜ ~ cat /var/spool/cron/crontabs/rms
cat: /var/spool/cron/crontabs/rms: Permission denied所以综上，可以得知，Crontab 的权限需要 +s 的权限，来使得用户执行的时候拥有所有者的权限也就是root的权限
详细分析
在chmod 的权限中除了标准的 rwx之外其实还有 强制位（s权限）和粘滞位（t权限）。
- s位 包含S_ISUID、S_ISGID两个常量在内，叫做强制位权限，作用在于设置使文件在执行阶段具有文件所有者的权限，相当于临时拥有文件所有者的身份.可执行的文件搭配这个权限，便能得到特权，任意存取该文件的所有者能使用的全部系统资源
- t位 /tmp和 /var/tmp 目录供所有用户暂时存取文件，亦即每位用户皆拥有完整的权限进入该目录，去浏览、删除和移动文件。
所以在一些需要使用更高级的权限来进行操作的 bin 文件的，一般都会拥有s位
如果遇到了linux 本身的小工具出现报错，strace 是一个很好的办法来看看内部调用出现的问题。
另外 crond 本身有一个 allow 和 deny 的文件，来控制那些用户可以使用 crond的功能