奇异现象其实也很根本---谈centos部署jenkins运行脚本遭遇的Permission Deny问题

 在centos7中,用rpm方式安装了jenkins持续集成&交付的环境,按照安装后的默认配置值,运行jenkins服务,jenkins进程所使用的用户,非root用户,是特殊的jenkins普通用户。在个人使用jenkins job中,执行某些脚本访问文件或目录时,就遭遇了Permission Deny问题。

      出现此问题时,由于有些Linux使用上的经验,个人用which xCommand查看到底能否在jenkins运行脚本里面找到相关xCommand运行命令,以及用绝对路径执行xCommand均得到了失败的提示。其中,which xCommand提示no Command;直接执行xCommand提示Permission Deny。

   对此问题,肯定首先想到先看看网上有什么已有解决方法,搜索了下网上的解决办法,大多数博文建议修改jenkins服务默认使用的用户为root或者修改jenkins用户的归属组为root Group。

    以此简单粗暴的方法解决此问题,但这种解决办法实际上违背了jenkins rpm的设计初衷!rpm安装好服务后,在默认情况下需要限制jenkins服务运行在非root级别,做一个沙箱限制,避免影响它人。不过,根据网上粗浅的解决办法,我大致知道是因为用户权限问题,但是具体出现在什么地方呢?

    我们知道在Linux的世界里面,对于某个文件的访问权限(RWX)分为三大类别:拥有者、同组成员、其他人。所以,用ls -al absolutePath/xCommand的方法查看命令的权限设置。初看权限列表,也是诧异的很,xCommand限定了拥有者具有全权限,同组和其他人都具有读和执行的权利,即r_x权限。那么xCommand应该可以访问和执行的?但为什么会报错呢?

     不解很久,也很疑惑,索性去倒杯水,整理下思路。后突然间有了点灵感,何不试试分析下所涉及的PATH路径上所有环节的访问权限,都是兼容的呢?顺藤摸瓜,逐段分析PATH路径上的DIR访问权限,终于发现某段同组和其他人权限设置上缺少读和执行的权利,这就是其中原因了!

    Linux检查了全路径上是否可以访问和执行,某一环节的权限不兼容,即可导致which xCommand终止搜索命令(虽然在PATH环境变量里面也设定了那个目录),和直接以绝对路径执行xCommand命令报Permission Deny的提示。

   从这次遭遇上,明白了以前所谓已经明白的RWX权限设置,实际上在经验和意识中还是很肤浅的。只有通过一次深度的互动接触,特别是有痛楚后突破的经历,才有深刻的理解!

   Linux上非root用户运行普通服务的原则,个人觉得还是非常应该坚持的,事实上形成了沙箱保护。而且,如果不是这次执拗的坚持必须以普通用户运行,则不会发现此不同的宝贝和明白以前之陋:)

  

你可能感兴趣的:(新潮流,小工具,XP编程,jenkins,Permission,Deny,非root用户)