facl, setfacl, partajare director, de ce cp pune permisiunile fișierului original în masca facl? ' nu ar trebui să fie un comportament cp -p?

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.