Crontab Permission denied

技术学习方面的东西,需要自己不断的区总结和复盘,把知识转化为自己的
也要理论作为经验的支柱,来使它更加健壮

问题现象

用户执行 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的功能

参考链接

留下点什么吧