Estou brincando com docker e db2, mas estou tendo problemas quando tento executar comandos como usuário db2inst1 em um contêiner em execução. Eu inicio o contêiner como (é 1 linha, mas eu o divido para facilitar a leitura):
docker run -itd --name mydb2 --privileged=true -p 50000:50000
-e LICENSE=accept
-e DB2INST1_PASSWORD=pelle_paltnacke
--mount type=volume,dst=${backupdir},volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=${addr}\",volume-opt=device=:${device}
-v /etc/passwd:/etc/passwd
-v /etc/group:/etc/group
-v /opt/nya/users/db2inst1:/opt/nya/users/db2inst1
-v /home/system/db2fenc1/:/home/system/db2fenc1/ ibmcom/db2
Agora, se eu tentar fazer:
docker exec --user db2inst1 -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
unable to find user db2inst1: no matching entries in passwd file
Como root não há problema:
docker exec -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash
e também --user root funciona bem:
docker exec --user root -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash
Então eu tentei com o uid do arquivo passwd montado:
docker exec --user 422 -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash
/etc/passwd é legível para todos. De qualquer forma, usar o uid não me leva muito longe:
docker exec --user 422 -ti mydb2 bash -c "db2licm -l"
bash: db2licm: command not found
então eu tento com:
docker exec --user 422 -ti mydb2 bash -c "whoami; . ~db2inst1/sqllib/db2profile;
db2licm -l"
db2inst1
bash: /opt/nya/users/db2inst1/sqllib/adm/db2licm: Permission denied
Este é apenas alguns comandos que executei para demonstrar o problema. Alguém tem uma explicação de por que o --user db2inst1 não é capaz de executá-los?
FWIW, tentei sem o nfs-mount, mas recebo o mesmo comportamento.
O contêiner em si parece estar funcionando bem. Se eu girar o contêiner como acima e:
#> docker exec -ti mydb2 bash
[root@0ee67959246f /]# mkdir -p /data/db/db2
[root@0ee67959246f /]# chown db2inst1:db2iadm1 /data/db/db2/
[root@0ee67959246f /]# su - db2inst1
[db2inst1@0ee67959246f ~]$ cd /data/backup/db2/wb11/MD000I11/
[db2inst1@0ee67959246f MD000I11]$ db2 "restore db MD000I11 incremental auto taken at 20220307141244 to /data/db/db2 into WD000I11"
DB20000I The RESTORE DATABASE command completed successfully.
EDIT: Uma observação interessante é:
docker exec --user 422 -ti mydb2 bash -c "id"
uid=422(db2inst1) gid=0(root) groups=0(root)
docker exec --user 422:422 -ti mydb2 bash -c "id"
uid=422(db2inst1) gid=422(db2iadm1) groups=422(db2iadm1)
docker exec --user 422:422 -ti mydb2 bash -c "whoami; .
~db2inst1/sqllib/db2profile; db2licm -l"
db2inst1
Product name: "DB2 Community Edition"
License type: "Community"
...
Infeliz:
docker exec --user db2inst1:db2iadm1 -ti mydb2 bash -c "id"
unable to find user db2inst1: no matching entries in passwd file
O problema parece não estar relacionado ao contêiner Db2. Eu criei um Dockerfile com:
pois é apenas conteúdo e poderia repetir os fenômenos. Eu até removi todas as coisas, exceto a montagem de /etc/passwd e /etc/groups, mas --user ainda falha.
Parece que --user X se torna o uid 1000 no contêiner, independentemente do nome de usuário X, o que o uid X tem em /etc/passwd não parece ser levado em consideração.
As duas opções que tentei para contornar esse problema são:
Crie um usuário "fictício" no Dockerfile:
Ou use o uid como argumento para --user:
Aqui eu usei --login para configurar o ambiente correto.
Usar o podman deve remover grande parte do incômodo, eu acho