Kubernetes中启动自定义Bash脚本的权限问题及疑问

问题场景 #

在Ubuntu容器中启动Bash脚本时遇到权限报错：

• 初始命令：command: ['sh', '-c', '/data/cleaner.sh']，执行时返回Permission denied错误
• 修改为command: ['sh', '-c', 'bash /data/cleaner.sh']后，脚本正常执行
• 容器内查看发现/data/cleaner.sh是指向..data/cleaner.sh的软链接，直接执行该软链接报错，通过bash调用则正常

对应的Kubernetes配置清单如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: cleaner-config
data:
  cleaner.sh: |-
    #!/bin/bash
    apt-get update
    apt-get install -y wget
    # some other commands...

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cleaner
spec: 
  selector:
    matchLabels:
      ver: one9      
  template:
    metadata:
      labels:
        ver: one9
    spec:
      containers:
        - name: kontener
          image: ubuntu:latest
          command: ['sh','-c', 'bash /data/cleaner.sh']
          volumeMounts:
          - name: config
            mountPath: "/data/"
      volumes:
        - name: config
          configMap:
            name: cleaner-config

原因解析 #

1. 脚本执行权限缺失 #

Kubernetes挂载ConfigMap时，默认会给文件设置644权限（用户可读可写，组和其他用户只读），没有可执行权限（x位）。当你直接执行/data/cleaner.sh时，操作系统会检查文件的可执行位，缺失的话就会抛出Permission denied错误。

而使用bash /data/cleaner.sh的方式，是让bash进程直接读取脚本内容并解释执行，这种方式不需要脚本本身具备可执行权限——只要文件有可读权限（644满足要求），bash就能加载并运行脚本。

2. 软链接的执行逻辑差异 #

/data/cleaner.sh是软链接，直接执行它时：

• 系统会先检查软链接文件本身的可执行权限（这里缺失），直接触发权限错误
• 即使软链接有权限，系统也会通过shebang（#!/bin/bash）调用bash，但前提是软链接本身能被执行

而用bash /data/cleaner.sh时，bash会直接解析软链接指向的目标文件内容，绕开了对软链接自身执行权限的检查，只要目标文件可读即可。

3. 补充：让脚本直接执行的方法 #

如果想要保留/data/cleaner.sh直接执行的方式，可以修改ConfigMap的挂载配置，添加defaultMode: 0755（八进制权限，代表用户可读可写可执行，组和其他可读可执行）：

volumes:
  - name: config
    configMap:
      name: cleaner-config
      defaultMode: 0755

这样挂载后的脚本就会具备可执行权限，直接执行/data/cleaner.sh也能正常运行。

内容的提问来源于stack exchange，提问作者macosmi