facl, setfacl, directory share, hvorfor setter cp de originale filtillatelsene i facl-masken? Bør ' ikke være cp -p-oppførsel?

Brukerne på dette systemet er forsiktige og har innstillingene til det helt private 0077. Brukerne vil imidlertid ha gruppespesifikke kataloger, der filer kan kopieres slik at de eksplisitt deles bare blant andre gruppemedlemmer. Det kan være flere slike aksjekataloger, selv om hver er spesifikk for en gruppe.

Det er ikke nok å sette gruppen klissete bit i en gitt katalog som skal brukes til deling. Selv om innstilling av den klissete biten fører til at gruppeeierskapet er riktig på filer som er plassert i katalogen, blir tillatelsene til nevnte filer ofte satt slik at filene ikke kan leses eller redigeres, dvs. faktisk ikke kan deles. De vises bare i katalogoppføringen. Dette er fordi noen brukere enten ikke tenker på, eller ikke vet hvordan, manuelt foretar den nødvendige gruppetillatelsesjusteringen for å tillate lesing og skriving. Vi kan gi dem en pause på dette fordi brukerne ikke er administratorer. acls kan brukes til å spesifisere at en bestemt gruppe har tilgang til filene i delekatalogen, uavhengig av hva gruppetillatelsene ville ha vært uten acls. Det er den perfekte løsningen, men det fungerer ikke helt.

I det følgende er den delte gruppen «customer_gateway» og eksempelbrukeren som prøver å dele en fil er «svw». Som det kan sees i transkripsjonen, er svw-brukeren medlem av customer_gateway-gruppen. Katalogen der deling skal forekomme kalles også «customer_gateway /»

Følgende bruker acls. Jeg angir gruppetillatelsene, standardgruppetillatelsene, masken og standardmasken. Det fungerer bra for filer som er opprettet i katalogen, eller for filer som er flyttet dit via cat (eller tar), men merkelig, ikke for filer som «cp» redigerte der:

# 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::--- > 

Det dette viser er at når en fil opprettes i katalogen, mottar den standard tillatelser og kan deles. Men brukerne lager ikke alltid filene sine der, ofte kopierer de dem der.

Men å gjøre en kopi er det samme, for å lage en kopi må vi først lage en ny fil. Vi snakker om en vanlig kopi her, ikke en beholder-kopi. Det er det samme som følgende skjema, som btw fungerer og kopierer en fil som kan deles i katalogen uavhengig av den opprinnelige gruppetillatelsen:

cat < data.in > shared/data.out 

fungerer fint, rør gjennom tjære fungerer også, men skjemaet

cp data.in shared/data.out 

mislykkes. cat ed-filen får standardmasken og standardtillatelsene. cp ed-filen bevarer rettighetene i acl-masken og gruppetillatelsene, som om den var en cp -p (men den var ikke «t), og dermed leser de effektive tillatelsene som den opprinnelige filen, ikke det som acls er satt til.

Som et nytt forsøk kjørte jeg dette eksperimentet med gruppe klebrig bit, chmod g + rwxs, sammen med facl ch angitt, og fikk nøyaktig de samme resultatene. Selv om katalogoppføringene er penere på grunn av gruppeeier som vises for alle delte filer. Jeg kjørte den også med bare gruppen klissete bit som ble satt, uten at setfacl. Det hadde også det samme resultatet for kopierte filer (så facls ser ganske ubrukelige ut for en katalog der filer kopieres inn for å bli delt).

På hvilket grunnlag og med hvilken begrunnelse skiller linux facls mellom forskjellige former for lage data? Hvorfor tvinge cp til å bevare tillatelser når den ikke har fått beskjed om å gjøre dette? Hvilken grunn vil rettferdiggjøre forvirringen forårsaket av dette skillet mellom katt og rør gjennom tjærearbeid, men cp fungerer ikke? Mangler jeg en magisk besvergelse som gjør dette skillet fordampe?

Er dette sammendraget riktig: facls vil tillate deg å overvinne eierskapet for å dele filer, det vil gjøre tillatelser mer tillatende enn umask når du «oppretter» filer, med mindre denne opprettelsen skyldes cp-kommandoen og med god grunn fordi … fordi hvorfor?

Kommentarer

• Hvilket operativsystem (linux distro og versjon) og hvilket filsystem bruker du? Ville det være greit å få folk til å bruke cat, kanskje via et dedikert shellscript for dette formålet?
• Har du tenkt at noen brukere i gruppen kan endre eller slette hvilken som helst fil, eller skal bare skaperen ha slike tillatelser? Med andre ord bare lese tillatelser (og kanskje utføre tillatelser) for o ther brukere.
• Debian 10. Fordi filopprettingen fungerer, har jeg ‘ kopiert gjennom tjære. Jeg ‘ vil pakke den opp som en proj_cp-kommando i / usr / local / bin. Imidlertid, hvis en bruker må bruke en spesiell kopikommando, kan man bare gå med gruppen klissete bit uten facls og angi tillatelsene. Jeg vil vite hvordan du stiller inn acls slik at cat tar og cp fungerer.Jeg ‘ tenker at det er et problem med acls med cp, ettersom de gjør cp -p-oppførselen i stedet for cp-oppførselen. Jeg ‘ gleder meg til å høre fra tillatelseseksperter.
• Gruppedeling er et tilbakevendende problem med variasjoner, som du påpeker. I dette tilfellet har programvareutviklere tilgang til katalogen for testutgivelse. Det er deres å mukke med. De kan jobbe i den katalogen, presse, trekke, installere i det virtuelle miljøet osv. Problemet kommer når de kopierer ting fra et annet område de har jobbet i, og deres omgivelser ikke er satt med gruppetillatelser. Det er forvirrende for dem fordi filoppretting og kopiering med tjære fungerer bra. Det er også morsomt at jeg må gi dem et kopi-skript som bare gjør hva cp gjør. ‘ acls ‘ de er magiske, jeg sier LOL
• Jeg er ingen tillatelsesekspert, men jeg håper at spørsmålene mine og svarene dine kan hjelpe ekspertene med å gi deg relevante svar.