Puncte:0

Discrepanța dintre /etc/group și „id -G”, ar putea fi legată de setarea docker?

drapel fr

Am creat un Dockerfile, folosesc ID-ul meu de utilizator actual pentru a rula aplicația, astfel încât containerul docker să ruleze cu aceeași permisiune a utilizatorului meu actual, având în vedere că containerul montează folderul gazdei pentru a efectua sarcina.

Nu sunt root pentru sistemul meu gazdă (local). Pentru a-mi face viața mai ușoară, adaug, de asemenea, rădăcină, grup sudo la acest cont de imagine Docker, astfel încât să pot efectua sarcina sudo pentru a instala lucrurile.

Iată o parte din Dockerfile:

(Ubuntu 18.04)

    ARG USERNAME='test'
    ARG UID=1000
    ARG GID=1000
    RUN apt-get update && apt-get install -yq openssh-server sudo
    RUN groupadd -g $GID grup de depanare
    RUN useradd -rm -d /home/$USERNAME -s /bin/bash -u $UID -g $GID -G roată $USERNAME
    RUN echo $USERNAME:test | chpasswd

Când construiesc imaginea docker, o folosesc

docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) --build-arg USERNAME=$(whoami) .

pentru a-mi transmite numele de utilizator și ID-ul de utilizator

iar când rulez imaginea docker (pentru a crea containerul docker), o folosesc și

docker run --detach -u $(id -u):$(id -g)

Totul este bine până în acest punct. Când folosesc „docker exec -it xxx bash” pentru a mă autentifica în acest container, numele meu de utilizator este corect (ben), id-ul meu de utilizator este corect (10023). id -G arată că sunt în 3 grupuri: 10001 (debuggroup), 0 (rădăcină), 27 (sudo) 10001 este adevăratul meu ID de grup dacă alerg id -g în gazdă.

Iată schimbarea: În gazdă, pe lângă grupul 10001, sunt și membru al grupului 10022 și 10033, așa că am permisiunea la un anumit folder. Acum, în container, deoarece utilizatorul nu este în 10022 și 10033, nu pot accesa acest folder.

Așa că am schimbat docker run comanda la:

docker run --detach -u $(id -u):$(id -g) $(id -G | sed -e 's/\</--group-add /g')

De fapt, funcționează și acum pot accesa folderul meu. id -G arată că sunt în 3 grupuri: 10001 (grup de depanare), 10022 (fără nume), 10033 (fără nume)

Dar: Nu mai sunt membru sudo și root. Lucrul interesant este, cat /etc/group arată că sunt încă în grupul sudo și root, dar nu mai am permisiunea de a mai sudo.

ben@a1559a984ac0:/$ grep ben /etc/group
root:x:0:ben
sudo:x:27:ben
ben@a1559a984ac0:/$ sudo ls
[sudo] parola pentru ben: 
Ben nu este în fișierul sudoers. Acest incident va fi raportat.

Există câteva postări StackExchange care vorbesc despre discrepanța despre grup, dar nu văd soluția pentru această problemă: contul meu este în /etc/group, dar nu în „grupuri” și „id -G”. De ce „ --group-add” al docker run comanda elimină grupul existent în care eram?

Cred că pot codifica " --group-add 0 " pentru a mă adăuga în rădăcină, dar acest lucru este încă frustrant (nu elegant). Vreo idee?

Fișierul docker este pentru Ubuntu 18.04, dar cred că nu are legătură cu versiunea.

Ben L avatar
drapel fr
Actualizare: de fapt adaug `--group-add sudo ` pentru a face contul sudo-able. Dar totuși vreau să știu cum să rezolvi problema discrepanței.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.