înregistrare Logare
Puncte:0
avatar Server

gcsfuse nu a putut deschide /dev/fuse: Permisiune refuzată

drapel de
Kohányi Róbert

Rulez următoarea comandă în interiorul unui container ca utilizator obișnuit, non-root

gcsfuse --foreground --debug_fuse --debug_fs --debug_gcs --debug_http my-bucket /data

și funcționează pe plan local când încep recipientul cu --privilegiat si asta e bine.

Dar nu același lucru funcționează pe Cloud Run (când se utilizează mediul de execuție de previzualizare de a doua generație). Primesc următoarea eroare:

2022-05-13 12:08:41.547 CEST gcs: 2022/05/13 10:08:41.546642 Req 0x1: -> ListObjects("") (46.897367ms): OK
2022-05-13 12:08:41.551 CEST /usr/bin/fusermount: nu s-a putut deschide /dev/fuse: Permisiune refuzată
2022-05-13 12:08:41.551 CEST mountWithArgs: mountWithConn: Mount: mount: rulează /usr/bin/fusermount: starea de ieșire 1

Toate celelalte linii de jurnal de depanare, HTTP, GCS etc. arată că totul funcționează.

Îmi creez utilizatorul astfel în my Dockerfile

RUN useradd -lmU joe\
  && mkdir -p /date \
  && chown -R joe:joe /data
UTILIZATOR joe

The spune docs ca eu ar trebui să ruleze gcsfuse ca utilizator care va folosi sistemul de fișiere, nu ca root, dar nu merge. Ai idee ce greșesc?

63
0 + 0
Priyashree Bhadra avatar
drapel in
Priyashree Bhadra
Aruncă o privire la acest [răspuns](https://stackoverflow.com/a/70430026/15803365).Posterul întrebării (https://stackoverflow.com/questions/70407189/unable-to-mount-bucket-with-gcsfuse-on-cloud-run) s-a confruntat cu un mesaj de eroare similar și nu a putut să monteze găleata cu gcsfuse pe Cloud Run.
0
Răspunde
drapel de
Kohányi Róbert
@PriyashreeBhadra Mulțumesc! Am văzut acea întrebare/răspuns, dar cred că folosirea lui `777` înfrânge scopul. Cu `root`, pentru mine totul funcționează, dar documentația promovează că nu ar trebui să se folosească `root`, așa că .. IMHO, acest lucru este suboptim. (Scopul fiind urmărirea unei abordări de *securitate în primul rând* atunci când se comercializează containere.) Poate că acest lucru nu este posibil, dar atunci acesta este răspunsul! :)
0
Răspunde
Priyashree Bhadra avatar
drapel in
Priyashree Bhadra
În mod implicit, toate inodele dintr-un sistem de fișiere gcsfuse apar ca fiind deținute de UID-ul și GID-ul procesului gcsfuse însuși, adică utilizatorul care a montat sistemul de fișiere. 644 și 755 sunt permisiunile implicite pentru toate inodele de fișiere și directoare dintr-un sistem de fișiere gcsfuse. Schimbarea modului inode (folosind chmod(2) sau similar) nu este acceptată, iar modificările sunt ignorate în tăcere.
0
Răspunde
Priyashree Bhadra avatar
drapel in
Priyashree Bhadra
Când montați compartimentul de stocare folosind gcsfuse, stratul de nucleu fuzibil restricționează accesul la sistemul de fișiere la utilizatorul care a montat sistemul de fișiere. Dacă doriți să oferiți acces altor utilizatori, puteți suprascrie acest comportament cu opțiunea allow_other mount împreună cu steagurile --uid și --gid. Cu toate acestea, rețineți că acest lucru poate avea implicații de securitate. Consultați [aici](https://github.com/googlecloudplatform/gcsfuse/blob/master/docs/semantics.md#inodes) pentru documentație.
0
Răspunde
drapel de
Kohányi Róbert
`un sistem de fișiere gcsfuse apare ca fiind deținut de UID-ul și GID-ul procesului gcsfuse în sine`, ceea ce este exact ceea ce vreau. Începeți `gcsfuse` ca `joe`, care nu funcționează în prezent. `Dacă doriți să oferiți acces altor utilizatori, puteți suprascrie acest comportament cu allow_other mount` Dar nu vreau, din motivul exact pe care ați menționat că acest lucru are implicații de securitate. Încep să văd că această problemă este mai degrabă o problemă de mediu Cloud Run, decât una `gcsfuse`, totuși, deoarece utilizatorii Cloud Run sunt potențial cei care ar putea folosi acest lucru cel mai mult, voi păstra această întrebare deschisă.
0
Răspunde
Priyashree Bhadra avatar
drapel in
Priyashree Bhadra
Cred că am văzut mulți oameni folosind alte servicii decât Cloud Run cu gcsfuse (de exemplu, ca instanța VM). După înțelegerea mea, această întrebare pare să fie o întrebare de permisiunea gcsfuse, mai degrabă decât Cloud Run, dar da, este valabilă dacă o persoană nu dorește să facă chmod cu permisiuni 777/666 sau să folosească allow_other. Am dat peste acest GitHub [comentar al problemei](https://github.com/GoogleCloudPlatform/gcsfuse/issues/236#issuecomment-361956965) care pare corect. Puteți încerca să vă adăugați la un grup de siguranțe și să schimbați grupul pentru a fi sigura în dispozitivul /dev/fuse. Anunță-mă dacă este posibil pentru tine
0
Răspunde
drapel de
Kohányi Róbert
`/dev/fuse` este disponibil doar atunci când containerul pornește efectiv, astfel încât utilizatorul meu `joe` fără `root` nu poate schimba proprietatea și, deoarece dispozitivul este deținut de `root:root`, nu pot face nimic în privința asta. Am încercat să creez grupul „fuzibil” și să-mi adaug utilizatorul la el, dar... nu părea să funcționeze. Voi încerca ori de câte ori am timp,... dar! Lucrurile funcționează la nivel local cu indicatorul `--priviliged` transmis către `docker run`, deși dispozitivul este deținut de `root:root`. În comentariul despre problema GitHub se spune că schimbă *grupul pentru a fuziona în dispozitivul `/dev/fuse`*. Atunci trebuie să se execute sub „rădăcină”.
0
Răspunde
drapel de
Kohányi Róbert
*Atunci trebuie să se execute sub root.* Ceea ce atunci este o soluție *un fel de*, deși puțin hacker. Mulțumesc că ai menționat această problemă GitHub, m-am abonat!
0
Răspunde
Puncte:1
Priyashree Bhadra avatar Server
drapel in
Priyashree Bhadra

Pentru comunitatea care caută un răspuns la această întrebare:

În conformitate cu aceasta Răspuns, adăugarea -file-mode=777 -dir-mode=777 împreună cu comanda gcsfuse în gcsfuse.sh pentru a activa citirea/scrierea în directorul montat al găleții GCS ar trebui să fie o opțiune, dar deoarece Kohányi Róbert a confirmat că nu servește scopului din motive de securitate. Am săpat mai departe și am găsit aceste informații foarte utile:

  • În mod implicit, toate inodele dintr-un sistem de fișiere gcsfuse apar ca fiind deținut de UID-ul și GID-ul procesului gcsfuse însuși, adică utilizatorul care a montat sistemul de fișiere. 644 și 755 sunt permisiunile implicite pentru toate inodurile de fișiere și directoare dintr-un sistem de fișiere gcsfuse. Schimbarea Modul inode (folosind chmod(2) sau similar) nu este acceptat și se modifică sunt ignorate în tăcere.

  • Când montați găleata de stocare folosind gcsfuse, nucleul siguranței strat restricționează accesul la sistemul de fișiere la utilizatorul care a montat fișierul sistem. Dacă doriți să oferiți acces altor utilizatori, puteți suprascrieți acest comportament cu opțiunea de montare allow_other împreună cu steagurile --uid și --gid. Cu toate acestea, rețineți că acest lucru poate avea implicații de securitate. Vedea Aici pentru documentare

  • Dacă o persoană nu dorește să facă chmod cu permisiuni 777/ 666 sau să utilizeze allow_other poate încerca să se adauge la un grup de siguranțe și să schimbe grup pentru a fuziona în dispozitivul /dev/fuse. Am dat peste acest GitHub emite comentariu ceea ce pare corect. Lucrurile funcționează local cu --privileged flag transmis către docker run chiar dacă dispozitivul este deținut de rădăcină:rădăcină. În comentariul problemei GitHub se spune că ei schimbați grupul pentru a fuziona în dispozitivul /dev/fuse. Ei trebuie să execute sub root atunci și asta ar putea fi o soluție pentru toți utilizatorii care nu vreau să treci prin 777/ allow_other/ --uid,--gid, 666 hack-uri.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.