facl, setfacl, katalogdelning, varför lägger cp de ursprungliga filbehörigheterna i facl-masken? Borde ' inte vara cp -p-beteende?

Användarna på det här systemet är försiktiga och har sina inställningar på det mycket privata 0077. Användarna vill dock ha gruppspecifika kataloger, där filer kan kopieras så att de uttryckligen delas bara bland andra gruppmedlemmar. Det kan finnas flera sådana aktiekataloger, men alla är specifika för en grupp.

Det räcker inte att ställa in gruppens klibbiga bit i en viss katalog som ska användas för delning. Även om inställningen av den klibbiga biten gör att gruppägarskapet är korrekt på filer som placeras i katalogen, ställs behörigheterna för nämnda filer ofta in så att filerna inte kan läsas eller redigeras, dvs faktiskt inte kan delas. De visas bara i katalogförteckningen. Detta beror på att vissa användare antingen inte tänker på eller inte vet hur man gör den manuella justeringen av gruppbehörigheter manuellt för att tillåta läsning och skrivning. Vi kan ge dem en paus på detta eftersom användare trots allt inte är administratörer. acls kan användas för att ange att en viss grupp har åtkomst till filerna i delningskatalogen, oberoende av vad gruppbehörigheterna skulle ha varit utan acls. Det är den perfekta lösningen, men det fungerar inte riktigt.

I det följande är den delade gruppen ”customer_gateway” och exempelanvändaren som försöker dela en fil är ”svw”. Som kan ses i transkriptet är svw-användaren medlem i gruppen customer_gateway. Katalogen där delning ska ske kallas också ”customer_gateway /”

Följande använder acls. Jag ställde in gruppbehörigheterna, standardgruppbehörigheterna, masken och standardmasken. Det fungerar bra för filer som skapats i katalogen eller för filer som flyttas dit via cat (eller tar), men konstigt nog, inte för filer som ”cp” redigerade där:

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

Vad detta visar är att när en fil skapas i katalogen får den standardbehörigheterna och kan delas. Men användare skapar inte alltid sina filer där, vanligtvis kopierar de dem där.

Men att göra en kopia är samma sak, för att göra en kopia måste vi först skapa en ny fil. Vi pratar om en vanlig kopia här, inte en bevara behörighetskopia. Det är samma som följande formulär, som, btw fungerar och kopierar en fil som kan delas i katalogen oberoende av dess ursprungliga gruppbehörigheter:

cat < data.in > shared/data.out 

fungerar bra, rörledning genom tjära fungerar också, men formuläret

cp data.in shared/data.out 

misslyckas. cat ed-filen får standardmask och standardbehörighet. cp ed-filen behåller sina behörigheter i acl-masken och gruppbehörigheterna, som om den var en cp -p (men det var inte ”t, och därmed de effektiva behörigheterna läste som originalfilen, inte vad acls har ställts in.

Som ett andra försök körde jag detta experiment med grupp klibbig bit, chmod g + rwxs, tillsammans med facl ch anges och fick exakt samma resultat. Även om katalogförteckningarna är vackrare på grund av att gruppägarskapet visas för alla delade filer. Jag körde det också med bara gruppen klibbig bit som ställts in utan att setfacl. Det hade också samma resultat för kopierade filer (så facls ser ganska värdelösa ut för en katalog där filer kopieras för att delas).

På vilken grund och med vilken motivering skiljer linux facls mellan olika former av skapa data? Varför tvinga cp att bevara behörigheter när den inte har fått veta att det ska göras? Vilken anledning skulle motivera den förvirring som orsakas av denna skillnad mellan katt och piping genom tjärarbete men cp fungerar inte? Saknar jag en magisk besvärjelse som skulle göra denna skillnad evaporate?

Är denna sammanfattning korrekt: facls tillåter dig att övervinna äganderätten för att dela filer, det kommer att göra behörigheter mer tillåtna än umask när du ”skapar” filer, såvida inte skapandet beror på cp-kommandot och av god anledning för … för varför?

Kommentarer

• Vilket operativsystem (Linux distro och version) och vilket filsystem använder du? Skulle det vara OK att få folk att använda cat, kanske via ett dedikerat shellscript för detta ändamål?
• Tänker du att någon användare i gruppen kan ändra eller ta bort vilken fil som helst, eller ska endast skaparen ha sådana behörigheter? Med andra ord bara läsbehörigheter (och kanske utföra behörigheter) för o andra användare.
• Debian 10. Eftersom filskapande fungerar har jag ’ pipat kopior genom tjära. Jag ’ paketerar det som ett projekt_cp-kommando i / usr / local / bin. Men om en användare måste använda ett speciellt kopieringskommando, kan man bara gå med gruppen klibbig bit utan facls och ställa in behörigheterna. Jag vill veta hur man ställer in acls så att cat tar och cp fungerar.Jag ’ Jag tror att det finns ett problem med acls med cp, eftersom de gör cp -p-beteendet istället för cp-beteendet. Jag ’ Jag ser fram emot att höra från behörighetsexperter.
• Gruppandel är ett återkommande problem med variationer, som du påpekar. I det här fallet har programutvecklare tillgång till katalogen för testrelease. Det är deras att muck med. De kan arbeta i den katalogen, trycka, dra, installera i den virtuella miljön etc. Problemet uppstår när de kopierar in saker från ett annat område de har arbetat i, och deras omfång är inte inställda med gruppbehörigheter. Det är förvirrande för dem eftersom filskapande och kopiering med tar fungerar bra. Det är också roligt att jag måste ge dem ett kopieringsskript som bara gör vad cp gör. ’ acls ’ de är magiska säger jag LOL
• Jag är ingen behörighetsexpert, men jag hoppas att mina frågor och dina svar kan hjälpa experterna att ge dig relevanta svar.