Владелец файлов сообщений контейнера Kubernetes

У меня есть ящик Debian, на котором запущен Kubernetes, там я получил ВСЮ рабочую среду с почти 50 развертываниями. Моя проблема в том, что в одном из модулей, на котором запущен сервер Odoo от имени непривилегированного пользователя, некоторые файлы (не все) создаются с пользователем root в качестве владельца.

это мое развертывание yaml:

---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  namespace: odoo
  name: app
spec:
  selector:
    matchLabels:
      app: odoo
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: odoo
    spec:
      securityContext:
        fsGroup: 1000
      containers:
      - name: odoo
        image: my-odoo
        command:
        - /docker-entrypoint.sh
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: odoo
        - containerPort: 110
          name: pop3
        - containerPort: 995
          name: pop3s
        - containerPort: 25
          name: smtp
        - containerPort: 993
          name: imaps
        volumeMounts:
        - name: home
          mountPath: /home
        - name: maildir
          mountPath: /var/mail
      volumes:
        - name: maildir
          hostPath:
            path: /mnt/odoo/maildir
        - name: home
          hostPath:
            path: /mnt/odoo/home

В моем сценарии точки входа я запускаю odoo, используя supervisord, вот мой conf:

[group:odoo]
programs = odoo-web, odoo-monitor, odoo-beat, odoo-worker-default-0, odoo-worker-cdr-1, odoo-worker-notifications-2, odoo-worker-default-notifications-3

[program:odoo-web]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin --proxy-mode


[program:odoo-worker-default-0]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin celery worker -l INFO -n default-0@%%h -c4 -Q odoo-10.0.default

[program:odoo-worker-cdr-1]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin celery worker -l INFO -n cdr-1@%%h -c1 -Q odoo-10.0.cdr

[program:odoo-worker-notifications-2]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin celery worker -l INFO -n notifications-2@%%h -c2 -Q odoo-10.0.notifications

[program:odoo-worker-default-notifications-3]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin celery worker -l INFO -n default-notifications-3@%%h -c2 -Q odoo-10.0.default,odoo-10.0.notifications


[program:odoo-beat]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin celery beat -s /home/odoo/var/celerybeat-schedule

[program:odoo-monitor]
user = odoo
directory = /home/odoo/var/run
command = /home/odoo/bin/odoo-bin celery flower`

Как вы можете видеть, все процессы выполняются как пользователь odoo с uid 1000.

Мой основной файловая система docker - overlay2.

Может ли кто-нибудь сказать мне, почему я запуталась с владельцем в файлах, созданных некорневым процессом?

0
задан 27 February 2019 в 17:00
2 ответа

Что ж, я нашел обходной путь: пользователь, которого я использую для запуска odoo, может выполнять sudo без пароля. Я удалил это. Теперь файлы не получают неправильные разрешения, так что это может быть ошибка в Odoo или в одной из его зависимостей или в самом python, которая позволяет обычному пользователю стать суперпользователем с помощью sudo, если в sudoers указан NOPASSWD.

0
ответ дан 4 December 2019 в 13:21

Как user1330614 упомянул в комментариях:

Я заметил, что пользователь, которого я использую для запуска odoo, может выполнять sudo без пароля. Я удалил это. Теперь файлы не получают неправильные разрешения, поэтому это может быть ошибка в Odoo или в одной из его зависимостей или в самом python, которая позволяет обычному пользователю стать суперпользователем с sudo , если NOPASSWD указан в sudoers .

Однако Тим Хокин предложил протестировать текущего пользователя контейнера, потому что:

Вы утверждали, что серверные модули Odoo работают как непривилегированные, но вы не устанавливаете runAsUser где угодно, поэтому они, вероятно, все еще работают как root:

  • kubectl exec -ti в вашем контейнере
  • run id и посмотрите, что такое uid / gid .
2
ответ дан 4 December 2019 в 13:21

Теги

Похожие вопросы