Brugerne på dette system er forsigtige og har deres umasks indstillet til det meget private 0077. Brugerne vil dog gerne have gruppespecifikke mapper, hvor filer kan kopieres for eksplicit at dele dem bare blandt andre gruppemedlemmer. Der kan være flere sådanne aktiekataloger, selvom hver er specifik for en gruppe.

Det er ikke nok at indstille gruppens klæbrigbit i en given mappe, der skal bruges til deling. Selvom indstilling af den sticky bit får gruppeejerskabet til at være korrekt på filer, der er placeret i biblioteket, er tilladelserne til de nævnte filer ofte indstillet således, at filerne ikke kan læses eller redigeres, dvs. faktisk ikke kan deles. De vises bare i telefonbogen. Dette skyldes, at nogle brugere enten ikke tænker på eller ikke ved, hvordan de manuelt foretager den nødvendige gruppetilladelsesjustering for at tillade læsning og skrivning. Vi kan give dem en pause i dette, fordi brugere trods alt ikke er administratorer. acls kan bruges til at angive, at en bestemt gruppe har adgang til filerne i delekataloget, uafhængigt af hvad gruppetilladelserne ville have været uden acls. Det er den perfekte løsning, men det fungerer ikke helt.

I det følgende er den delte gruppe “customer_gateway”, og den eksempelbruger, der prøver at dele en fil, er “svw”. Som det kan ses i udskriften, er svw-brugeren medlem af gruppen customer_gateway. Kataloget, hvor deling skal forekomme, kaldes også “customer_gateway /”

Følgende bruger acls. Jeg indstiller gruppetilladelserne, standardgruppetilladelserne, masken og standardmasken. Det fungerer godt for filer, der er oprettet i biblioteket, eller for filer, der flyttes der via cat (eller tar), men underligt, ikke for filer, der “cp” ed 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::--- >

Hvad dette viser er, at når en fil oprettes i biblioteket, modtager den standardtilladelserne og kan deles. Men brugerne opretter ikke altid deres filer der, ofte cp de dem der.

Men at lave en kopi er den samme ting, for for at lave en kopi skal vi først oprette en ny fil. Vi taler om en almindelig kopi her, ikke en bevare tilladelseskopi. Den er den samme som følgende formular, som btw fungerer og kopierer en fil, der kan deles i biblioteket uafhængigt af dens oprindelige gruppetilladelser: 

cat < data.in > shared/data.out

fungerer fint, rørføring gennem tjære fungerer også, men formularen 

cp data.in shared/data.out

mislykkes. cat ed-fil får standardmasken og standardtilladelserne. cp ed-filen bevarer sine tilladelser i acl-masken og gruppetilladelserne, som om den var en cp -p (men det var ikke “t), og dermed læses de effektive tilladelser som den originale fil, ikke hvad acls er indstillet til.

Som et andet forsøg kørte jeg dette eksperiment med gruppe klæbrig bit, chmod g + rwxs, sammen med facl ch angivet og fik nøjagtigt de samme resultater. Selvom katalogoversigterne er pænere på grund af gruppeejerskabet, der vises for alle delte filer. Jeg kørte det også med bare den gruppe, der blev indstillet, uden at sætfacl. Det havde også det samme resultat for kopierede filer (så facls ser ret ubrugelige ud for en mappe, hvor filer kopieres til, der skal deles).

På hvilket grundlag og med hvilken begrundelse skelner Linux facls mellem forskellige former for opretter data? Hvorfor tvinge cp til at bevare tilladelser, når det ikke er blevet bedt om at gøre dette? Hvilken årsag ville retfærdiggøre den forvirring, der er forårsaget af denne skelnen mellem kat og rør gennem tjærefungerende, men cp fungerer ikke? Mangler jeg en magisk besværgelse, der gør denne forskel fordampe?

Er dette resume korrekt: facls giver dig mulighed for at overvinde ejerskabet for at dele filer, det vil gøre tilladelser mere tilladelige end umask, når du “opretter” filer, medmindre oprettelsen skyldes cp-kommandoen og af god grund, fordi … fordi hvorfor?

Kommentarer

  • Hvilket operativsystem (Linux distro og version) og hvilket filsystem bruger du? Ville det være OK at få folk til at bruge cat, måske via et dedikeret shellscript til dette formål?
  • Har du til hensigt at enhver bruger i gruppen kan ændre eller slette enhver fil, eller skal kun skaberen have sådanne tilladelser? Med andre ord kun læse tilladelser (og måske udføre tilladelser) til o Deres brugere.
  • Debian 10. Fordi filoprettelse fungerer, har jeg ‘ kopieret gennem tjære. Jeg ‘ vil pakke den op som en proj_cp-kommando i / usr / local / bin. Men hvis en bruger skal bruge en speciel kopi-kommando, kan man bare gå med gruppen klæbrig bit uden facls og indstille tilladelserne. Jeg vil gerne vide, hvordan man indstiller acls, så cat tar og cp fungerer.Jeg ‘ tænker, at der er et problem med acls med cp, da de udfører cp -p-opførsel i stedet for cp-opførsel. Jeg ‘ glæder mig til at høre fra tilladelseseksperter.
  • Gruppedeling er et tilbagevendende problem med variationer, som du påpeger. I dette tilfælde har softwareudviklere adgang til testudgivelsesmappen. Det er deres at mukke med. De kan arbejde i den mappe, skubbe, trække, installere i det virtuelle miljø osv. Problemet opstår, når de kopierer ting ind fra et andet område, de har arbejdet i, og deres umasker er ikke indstillet med gruppetilladelser. Det er forvirrende for dem, fordi filoprettelse og kopiering med tjære fungerer fint. Det er også sjovt, at jeg er nødt til at give dem et kopi script, der bare gør hvad cp gør. ‘ acls ‘ de er magiske, jeg siger LOL
  • Jeg er ingen tilladelsesekspert, men jeg håber, at mine spørgsmål og dine svar kan hjælpe eksperterne med at give dig relevante svar.

Svar

Denne kendsgerning ved at oprette et bibliotek, hvor brugere kan gå ind i er ret simpelt og let kan gøres.

  • For det første skal du finde et passende sted at lave denne mappe, jeg anbefaler at gøre det under en mappe, der er tilgængelig til alle (for øjeblikket). Brug kommandoen sudo mkdir for at oprette din nye mappe.

  • For det andet du skal oprette en gruppe, en gruppe er simpelthen en samling af brugere, der afrundes for at begrænse eller få adgang til bestemte dele af et linux-system. Du har muligvis set grupper, når du skriver kommandoen ls -l , der viser noget som dette:

rwxrwxrwx 3 rodadministratorer 4736 24. okt 12:32 File1.doc

Den del, der siger root er ejeren og ** admins ** er den gruppe, der ejer filen. Grupper sikrer en nem måde at give bestemte personer mulighed for at se filer. For at få en gruppe til at skrive “sudo groupadd”, vil dette være den gruppe, der bruges til biblioteket.

  • Når grupperne er oprettet, kan du tilføje brugere til den, som du vil have adgang til biblioteket ved at ved hjælp af følgende kommando sudo adduser Dette giver dig mulighed for at tilføje brugere, du kan kontrollere, om brugeren er i gruppen med gruppen kommando.

Når dette er gjort, skal du søge i den mappe, du oprettede, og indstille gruppetilladelsen til 7 (rwx), husk at du kan justere disse til dine præferencer, men 7 giver brugere af gruppen fulde tilladelser til biblioteket kan du gøre dette ved at skrive “sudo chmod 770”

Derefter skal du ændre gruppeejerskabet af biblioteket, så gruppeejeren af biblioteket er den gruppe, du har lavet, gør dette med med følgende kommando “sudo chown -R: gruppenavn.

Når dette er gjort, kan du nu tilføje den, du ønsker, til gruppen, og de har adgang til at kopiere og dele filer, så længe de ey er i den specifikke gruppe for at få adgang til biblioteket. Giv mig besked, hvis du fandt dette nyttigt !!!!!!

Kommentarer

  • Tak, jeg klargjorde det oprindelige indlæg for at forklare, hvorfor jeg ikke gjorde det ‘ Brug ikke denne manuelle tilgang.

Svar

I fjerner alle ACLer og bruger kun bruger- og gruppetilladelser. Derefter chmod 777 den mappe, du vil have alle adgang til. Test derefter din adgang.

Derefter chmod 770 mappetestadgangen igen.

Når dette fungerer som det skal tilføjes alias tilbage ad gangen.

Hvis de ikke har brug for at udføre tilladelser, kan du reducere det endnu lavere til rw *, rx *, *** med chmod 660 mappenavn

Husk i den periode, hvor du ikke har nogen ACLer og chmod 777 tilladelser din mappen vil være åben for alle, så lad det ikke være sådan.

Kommentarer

  • Ikke alle, kun mennesker i en bestemt gruppe. Jeg kunne indstille gruppen klæbrig bit i biblioteket. Problemet er, at brugerne derefter placerer filer i biblioteket, og gruppen er korrekt, men de enten ‘ ved ikke eller glemmer at indstille gruppeadgangen. acls kan bruges til at angive, at en bestemt gruppe har adgang til filerne uafhængigt af deres gruppetilladelser. Det er det perfekte svar. Problemet er, at acls har en maske, og cp rydder acl-masken for at matche brugernes umask, så de effektive tilladelser tillader ikke, at filerne kan læses.

Svar

Jeg prøvede det. Det ser ud til, at umask klarer gruppetilladelserne, da gruppetilladelserne er masken for ACL. Det blokerer alle grupper og ACLer.

Et arbejde rundt er at gøre umask mindre restriktiv.For at gøre dette sikkert skal du tilføje en gruppe til hver bruger og gøre denne gruppe til standardgruppen. (se Hvorfor har hver bruger deres egen gruppe? ).

Dette er ikke ideelt, da der stadig er en sag for forskellige umasks (g = rx og g = rwx). Denne strategi fjerner kun behovet for ingen gruppetilladelser.

Kommentarer

  • Ja, det var det, jeg havde gjort, jeg satte i stedet brugermasker til 007 af 077 som en løsning. Det er dog ikke ´, da mange filer stadig har mindre tilladelser og bliver kopieret ind. Det, jeg håbede at lære her, var, hvorfor cp opfører sig sådan. Det ser ud til, at dette burde være cp -p opførsel. Jeg havde håbet, at nogen her kunne forklare det.

Svar

Alle svar hidtil har givet råd om, hvordan til at håndtere deling af filer via gruppekataloger. Non har besvaret dit hovedspørgsmål, tror jeg, hvilket var: Hvorfor opfører cp a b sig som om cp -p a b blev specificeret? mand-siden taler faktisk ikke om det, men texinfo har detaljerne. info coreutils "cp invocation" viser: 

 ‘-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. ...

Så hvis destinationen findes, erstattes indholdet, men tilstandsbitene er ikke ændret. Hvis destinationen ikke findes, kopieres tilstandsbits fra kilden.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *