Utilizatorii acestui sistem sunt atenți și au mascarile setate la 0077 foarte privat. Cu toate acestea, utilizatorii ar dori să aibă directoare specifice grupului, unde fișierele pot fi copiate astfel încât să le împărtășească în mod explicit doar între alți membri ai grupului. Pot exista mai multe astfel de directoare de partajare, deși fiecare este specific unui grup.

Setarea bitului lipicios de grup pe un anumit director pentru a fi folosit pentru partajare nu este suficientă. Deși setarea bitului lipicios face ca proprietatea grupului să fie corectă pe fișierele plasate în director, permisiunile pentru fișierele menționate sunt deseori setate astfel încât fișierele să nu poată fi citite sau editate, adică nu pot fi de fapt partajate. Ele apar doar în lista de directoare. Acest lucru se datorează faptului că unii utilizatori fie nu se gândesc, fie nu știu cum să efectueze manual ajustarea necesară a permisiunilor de grup pentru a permite citirea și scrierea. Le putem oferi o pauză în acest sens, deoarece utilizatorii nu sunt administratori, la urma urmei. acls poate fi folosit pentru a specifica faptul că un anumit grup are acces la fișierele din directorul de partajare, independent de ceea ce ar fi fost permisiunile de grup fără acls. Aceasta este soluția perfectă, dar nu prea funcționează.

În cele ce urmează, grupul partajat este „client_gateway”, iar exemplul de utilizator care încearcă să partajeze un fișier este „svw”. După cum se poate vedea în transcriere, utilizatorul svw este membru al grupului customer_gateway. Directorul în care trebuie să aibă loc partajarea se mai numește „client_gateway /”

Următorul folosește acls. Am setat permisiunile de grup, permisiunile de grup implicite, masca și masca implicită. Funcționează bine pentru fișierele create în director sau pentru fișierele mutate acolo prin cat (sau tar), dar în mod ciudat, nu pentru fișierele care au „cp” editat acolo:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

Ceea ce arată este că atunci când un fișier este creat în director, acesta primește permisiunile implicite și este partajabil. Dar utilizatorii nu își creează întotdeauna fișierele acolo, de obicei le cp acolo.

Dar a face o copie este același lucru, pentru că pentru a face o copie trebuie mai întâi să creăm un fișier nou. Vorbim despre o copie simplă aici, nu o copie a permisiunilor de păstrare. Este la fel ca următoarea formă, care, btw funcționează și copiază un fișier care va fi partajabil în director independent de permisiunile sale de grup inițiale:

cat < data.in > shared/data.out 

funcționează bine, canalizarea prin tar funcționează și ea, dar forma

cp data.in shared/data.out 

eșuează. cat ed fișierul primește masca implicită și permisiunile implicite. Fișierul cp ed își păstrează permisiunile în masca acl și în permisiunile de grup, ca și cum ar fi fost un cp -p (dar nu era „t) și, astfel, permisiunile efective citite ca fișierul original, nu ceea ce au fost setate acls-urile.

Ca a doua încercare, am rulat acest experiment cu grupați bitul lipicios, chmod g + rwxs, împreună cu facl ch și a obținut exact aceleași rezultate. Deși listele de directoare sunt mai frumoase datorită proprietății grupului afișate pentru toate fișierele partajate. De asemenea, l-am rulat doar cu setul de biți de grup, fără setfacl. De asemenea, a avut același rezultat pentru fișierele copiate (astfel încât facls-urile par destul de inutile pentru un director în care fișierele sunt copiate pentru a fi partajate).

Pe ce bază și cu ce justificare face Linux facls distinge între diferite forme de creează date? De ce să forțăm CP să păstreze permisiunile atunci când nu i s-a spus să facă acest lucru? Ce motiv ar justifica confuzia cauzată de această distincție între pisică și piping prin gudron, dar cp nu funcționează? Îmi lipsește un descântec magic care ar face această distincție Evaporați?

Este corect acest rezumat: facls vă va permite să depășiți calitatea de proprietar pentru a partaja fișiere, va face permisiunile mai permisive decât umask atunci când „creați” fișiere, cu excepția cazului în care această creație se datorează comenzii cp și dintr-un motiv bun pentru că … pentru că de ce?

Comentarii

  • Ce sistem de operare (linux distro și versiune) și ce sistem de fișiere folosiți? Ar fi OK să îi faci pe oameni să utilizeze cat, poate printr-un shellscript dedicat în acest scop?
  • Înțelegi că orice utilizator din grup poate modifica sau șterge orice fișier sau ar trebui doar creatorul să aibă astfel de permisiuni? Cu alte cuvinte, numai permisiuni de citire (și poate executa permisiuni) pentru alți utilizatori.
  • Debian 10. Deoarece crearea fișierelor funcționează, am ‘ am introdus copii prin tar. ‘ voi împacheta acest lucru ca comandă proj_cp în / usr / local / bin. Cu toate acestea, dacă un utilizator trebuie să utilizeze o comandă specială de copiere, atunci ar putea merge doar cu bitul lipicios de grup fără facls și să seteze permisiunile. Vreau să știu cum să setez acl-urile astfel încât cat tar și cp să funcționeze.’ cred că există o problemă cu acls cu cp, deoarece aceștia fac comportamentul cp -p în loc de comportamentul cp. ‘ Aștept cu nerăbdare să aud de la experți în permisiuni.
  • Cota de grup este o problemă recurentă cu variații, după cum subliniați. În acest caz, dezvoltatorii de software au acces la directorul versiunii de testare. Este al lor cu care să se tâmpească. Pot lucra în acel director, împinge, trage, instala în mediul virtual etc. Problema apare atunci când copiază lucruri dintr-o altă zonă în care au lucrat și masca lor nu este setată cu permisiuni de grup. Este confuz pentru ei, deoarece crearea și copierea fișierelor cu tar funcționează bine. De asemenea, este amuzant că trebuie să le dau un script de copiere care să facă ceea ce face CP. ‘ acls ‘ sunt magice spun LOL
  • Nu sunt expert în permisiuni, dar sper că întrebările mele iar răspunsurile dvs. vă pot ajuta pe experți să vă ofere răspunsuri relevante.

Răspuns

Acest fapt de a crea un director în care utilizatorii pot intra este destul de simplu și se poate face cu ușurință.

  • În primul rând va trebui să găsiți un loc adecvat pentru a crea acest director, vă recomand să îl faceți într-un director accesibil tuturor (pentru moment). Utilizați comanda sudo mkdir pentru a crea noul dvs. director.

  • În al doilea rând trebuie să faceți un grup, un grup este pur și simplu o colecție de utilizatori care sunt rotunjiți pentru a restricționa sau accesa anumite părți ale unui sistem Linux. Este posibil să fi văzut grupuri atunci când tastați comanda ls -l care listează ceva de genul acesta:

rwxrwxrwx 3 root admins 4736 24 Oct 12:32 File1.doc

Partea care spune root este proprietarul și ** administratorii ** este grupul care deține fișierul. Grupurile asigură un mod ușor de a permite anumitor persoane să vizualizeze fișiere. Pentru a face un grup, tastați „sudo groupadd, acesta va fi grupul utilizat pentru director.

  • Odată ce grupurile au fost create, puteți adăuga utilizatori la care doriți să accesați directorul, prin folosind următoarea comandă sudo adduser Acest lucru vă va permite să adăugați utilizatori pe care îi puteți verifica dacă utilizatorul este în grupul cu grupul comanda.

Odată ce ați terminat, navigați la directorul pe care l-ați creat și setați permisiunea de grup la 7 (rwx) amintiți-vă că le puteți ajusta în funcție de preferințele dvs., dar 7 oferă utilizatorilor grupului permisiuni complete în director, puteți face acest lucru tastând „sudo chmod 770”

Apoi trebuie să schimbați proprietatea grupului pentru director, astfel încât proprietarul grupului din director este grupul pe care l-ați făcut, faceți acest lucru cu cu următoarea comandă „sudo chown -R: groupname.

Odată ce toate acestea au fost făcute, puteți adăuga acum pe oricine doriți grupului și vor avea acces să copieze și să partajeze fișiere atâta timp cât sunt în acel grup specific pentru a accesa directorul. Vă rog să-mi spuneți dacă vi s-a părut util acest lucru !!!!!!

Comentarii

  • Mulțumesc, am clarificat postarea originală pentru a explica de ce nu ‘ nu utilizați această abordare manuală.

Răspuns

I ar elimina toate acl-urile și ar folosi doar permisiunile de utilizator și grup. Apoi chmod 777 dosarul la care doriți să aibă acces toată lumea. Apoi testați-vă accesul.

Apoi chmod 770 testează din nou accesul la folder.

Când funcționează așa cum ar trebui, apoi adăugați acl-uri înapoi pe rând.

Dacă nu au nevoie de permisiuni de executare, ați putea să o reduceți chiar mai jos la rw *, rx *, *** cu chmod 660 foldername

Amintiți-vă pentru perioada în care nu aveți permisiuni ACL și chmod 777 folderul va fi larg deschis tuturor, așa că nu lăsați așa.

Comentarii

  • Nu toată lumea, doar persoanele dintr-un anumit grup. Aș putea seta bitul lipicios al grupului pe director. Problema este că atunci utilizatorii pun fișiere în director, iar grupul este corect, dar fie nu ‘ nu știu, fie uită, să seteze accesul grupului. acls pot fi utilizate pentru a specifica faptul că un anumit grup are acces la fișiere independent de permisiunile grupului lor. Acesta este răspunsul perfect. Problema este că acls au o mască, iar cp șterge masca acl pentru a se potrivi cu masca utilizatorilor, astfel încât permisiunile efective nu permit citirea fișierelor.

Răspuns

Am încercat. Se pare că umaskul clobează permisiunile de grup, deoarece permisiunile de grup sunt masca ACL. Blochează toate grupurile și ACL-urile.

O soluție este de a face masca mai puțin restrictivă.Pentru a face acest lucru în siguranță, trebuie să adăugați un grup pentru fiecare utilizator și să faceți din acest grup grupul implicit. (consultați De ce fiecare utilizator are propriul grup? ).

Acest lucru nu este ideal, deoarece există încă un caz pentru diferite mascări (g = rx și g = rwx). Această strategie elimină doar necesitatea de a nu avea permisiuni de grup.

Comentarii

  • Da, asta am făcut, am setat măștile de utilizator la 007 din 077 ca soluție. Cu toate acestea, nu este ´ perfect, deoarece multe fișiere au în continuare permisiuni mai mici și sunt copiate. Lucrul pe care am sperat să-l învăț aici a fost motivul pentru care cp se comportă astfel. Mi se pare că acesta ar trebui să fie comportamentul cp -p. Sperasem că cineva de aici ar putea să-l explice.

Răspuns

Toate răspunsurile de până acum au dat sfaturi despre cum pentru a face față partajării fișierelor prin directoare de grup. Non v-a răspuns la întrebarea principală, cred, care a fost: De ce se comportă cp a b de parcă s-ar fi specificat cp -p a b? pagina de om nu vorbește despre asta, într-adevăr, dar texinfo are detaliile. info coreutils "cp invocation" arată:

 ‘-p’ ‘--preserve[=ATTRIBUTE_LIST]’ Preserve the specified attributes of the original files. ... ... In the absence of this option, the permissions of existing destination files are unchanged. Each new file is created with the <=== mode of the corresponding source file minus the set-user-ID, <=== set-group-ID, and sticky bits as the create mode; the operating system then applies either the umask or a default ACL, possibly resulting in a more restrictive file mode. ... 

Deci, dacă există destinația, conținutul este înlocuit, dar biții de mod sunt neschimbat. Dacă destinația nu există, biții de mod sunt copiați din sursă.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *