De gebruikers op dit systeem zijn voorzichtig en hebben hun umasks ingesteld op de zeer persoonlijke 0077. De gebruikers zouden echter graag groepsspecifieke mappen willen hebben, waar bestanden kunnen worden gekopieerd om ze expliciet te delen met andere groepsleden. Er kunnen meerdere van dergelijke gedeelde mappen zijn, hoewel ze allemaal specifiek zijn voor een groep.

Het instellen van de sticky bit van de groep op een bepaalde directory om te gebruiken voor delen is niet voldoende. Hoewel het instellen van de sticky bit ervoor zorgt dat het groepseigendom correct is voor bestanden die in de directory zijn geplaatst, zijn de machtigingen voor die bestanden vaak zo ingesteld dat de bestanden niet kunnen worden gelezen of bewerkt, d.w.z. dat ze niet daadwerkelijk kunnen worden gedeeld. Ze verschijnen gewoon in de directorylijst. Dit komt doordat sommige gebruikers er niet aan denken of niet weten hoe ze handmatig de vereiste aanpassing van de groepstoestemmingen moeten maken om lezen en schrijven toe te staan. We kunnen ze hier een pauze in geven, omdat gebruikers tenslotte geen beheerders zijn. acls kan worden gebruikt om aan te geven dat een bepaalde groep toegang heeft tot de bestanden in de gedeelde map, onafhankelijk van wat de machtigingen van de groep zouden zijn zonder acls. Dat is de perfecte oplossing, maar het werkt niet helemaal.

In het volgende is de gedeelde groep “customer_gateway” en de voorbeeldgebruiker die een bestand probeert te delen is “svw”. Zoals te zien is in het transcript, is de svw-gebruiker lid van de customer_gateway-groep. De directory waar het delen moet plaatsvinden, wordt ook “customer_gateway /” genoemd.

Het volgende gebruikt acls. Ik heb de groepsmachtigingen, de standaardgroepsmachtigingen, het masker en het standaardmasker ingesteld. Het werkt goed voor bestanden die in de directory zijn gemaakt, of voor bestanden die daar naartoe zijn verplaatst via cat (of tar), maar vreemd genoeg niet voor bestanden die daar “cp” zijn: 

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

Wat dit laat zien, is dat wanneer een bestand in de directory wordt aangemaakt, het de standaardrechten krijgt en kan worden gedeeld. Maar gebruikers maken hun bestanden niet altijd daar, gewoonlijk cp ze ze daar.

Maar kopiëren is hetzelfde, want om een kopie te maken, moeten we eerst een nieuw bestand maken. We hebben het over hier een gewone kopie, geen kopie van de behouden machtigingen. Het is hetzelfde als het volgende formulier, dat trouwens wel werkt en een bestand kopieert dat in de directory kan worden gedeeld, onafhankelijk van de oorspronkelijke groepstoestemmingen: 

cat < data.in > shared/data.out

werkt prima, piping through tar werkt ook, maar de vorm 

cp data.in shared/data.out

mislukt. De cat ed-bestand krijgt het standaardmasker en de standaardrechten. Het cp ed-bestand behoudt zijn rechten in het acl-masker en de groepsrechten, alsof het a cp -p (maar het was niet “t), en dus lezen de effectieve permissies als het originele bestand, niet zoals de acls zijn ingesteld.

Als tweede poging heb ik dit experiment uitgevoerd met de group sticky bit, chmod g + rwxs, samen met de facl ch anges, en kreeg exact dezelfde resultaten. Hoewel de directoryvermeldingen mooier zijn omdat het groepseigendom wordt weergegeven voor alle gedeelde bestanden. Ik heb het ook uitgevoerd met alleen het sticky bit van de groep, zonder de setfacl. Het had ook hetzelfde resultaat voor gekopieerde bestanden (dus facls lijken tamelijk nutteloos voor een map waarin bestanden worden gekopieerd om te worden gedeeld).

Op welke basis en met welke rechtvaardiging maakt linux facls onderscheid tussen verschillende vormen van data aanmaken? Waarom cp dwingen om rechten te behouden als het niet is verteld dit te doen? Welke reden zou de verwarring rechtvaardigen die wordt veroorzaakt door dit onderscheid tussen kat en piping door teerwerkend maar cp werkt niet? Mis ik een magische bezwering die dit onderscheid zou maken verdampen?

Is deze samenvatting correct: facls zal je toelaten om het eigendom te overwinnen om bestanden te delen, het zal permissies meer permissief maken dan de umask bij het “creëren” van bestanden, tenzij die creatie te wijten is aan het cp commando en om een goede reden omdat … want waarom?

Reacties

  • Welk besturingssysteem (linux distro en versie) en welk bestandssysteem gebruik je? Zou het oké zijn om mensen cat te laten gebruiken, misschien via een speciaal shellscript voor dit doel?
  • Bent u van plan dat elke gebruiker in de groep kan wijzigen of verwijderen elk bestand, of zou alleen de maker dergelijke machtigingen moeten hebben? Met andere woorden: alleen leesmachtigingen (en misschien uitvoeringsmachtigingen) voor de o andere gebruikers.
  • Debian 10. Omdat het maken van bestanden werkt, heb ik ‘ kopieën door tar geleid. Ik ‘ verpak dat als een proj_cp commando in / usr / local / bin. Als een gebruiker echter een speciaal kopieercommando moet gebruiken, kan men gewoon met de groep sticky bit gaan zonder facls en de permissies instellen. Ik wil weten hoe ik de acls moet instellen zodat cat tar en cp werken.Ik ‘ m denk dat er een probleem is met acls met cp, aangezien ze het cp -p-gedrag uitvoeren in plaats van het cp-gedrag. Ik ‘ kijk er naar uit om te horen van toestemmingsdeskundigen.
  • Het delen van groepen is een terugkerend probleem met variaties, zoals u aangeeft. In dit geval hebben softwareontwikkelaars toegang tot de testrelease-directory. Het is van hen om mee te rotzooien. Ze kunnen in die directory werken, pushen, trekken, installeren in de virtuele omgeving enz. Het probleem komt wanneer ze dingen kopiëren vanuit een ander gebied waarin ze hebben gewerkt, en hun umasks zijn niet ingesteld met groepsmachtigingen. Het is voor hen verwarrend omdat het aanmaken en kopiëren van bestanden met tar prima werkt. Het is ook grappig dat ik ze een copy-script moet geven dat precies doet wat cp doet. ‘ acls ‘ ze zijn magisch, ik zeg LOL
  • Ik ben geen machtigingsdeskundige, maar ik hoop dat mijn vragen en uw antwoorden kunnen de experts helpen om u relevante antwoorden te geven.

Antwoord

Dit feit van het maken van een directory waarin gebruikers kunnen binnengaan is vrij eenvoudig en kan gemakkelijk worden gedaan.

  • Ten eerste moet je een geschikte plaats vinden om deze map te maken, ik raad aan om deze onder een map te plaatsen die toegankelijk is voor iedereen (op dit moment). Gebruik het commando sudo mkdir om uw nieuwe map te maken.

  • Ten tweede je moet een groep maken, een groep is gewoon een verzameling gebruikers die naar boven worden afgerond om bepaalde delen van een linux-systeem te beperken of toegang te krijgen. Je hebt misschien groepen gezien bij het typen van het ls -l commando dat zoiets als dit vermeldt:

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

Het gedeelte dat zegt root is de eigenaar en ** admins ** is de groep die eigenaar is van het bestand. Groepen zorgen ervoor dat bepaalde mensen op een gemakkelijke manier bestanden kunnen bekijken. Om een groep te maken, typ je de “sudo groupadd, dit is de groep die voor de directory wordt gebruikt.

  • Zodra de groepen zijn gemaakt, kun je er gebruikers aan toevoegen die je wilt openen in de directory, door met het volgende commando sudo adduser Hiermee kunt u gebruikers toevoegen die u kunt controleren of de gebruiker deel uitmaakt van de groep met de groep commando.

Als dit klaar is, blader je naar de map die je hebt aangemaakt en stel je de groepstoestemming in op 7 (rwx) onthoud dat je deze kunt aanpassen aan je voorkeuren, maar 7 geeft gebruikers van de groep volledige machtigingen naar de directory, je kunt dit doen door “sudo chmod 770” te typen.

Vervolgens moet je het groepseigendom van de directory wijzigen, zodat de groepseigenaar van de directory de groep is die je hebt aangemaakt, doe dit met met het volgende commando “sudo chown -R: groepsnaam.

Zodra dit allemaal is gedaan, kunt u nu wie u maar wilt aan de groep toevoegen en zij hebben toegang om bestanden te kopiëren en te delen zolang de ey zijn in die specifieke groep om toegang te krijgen tot de directory. Laat het me weten als je dit nuttig vond !!!!!!

Reacties

  • Bedankt, ik heb het oorspronkelijke bericht verduidelijkt om uit te leggen waarom ik het niet deed ‘ gebruik deze handmatige benadering niet.

Antwoord

I zou alle acl “s verwijderen en gewoon gebruikers- en groepsmachtigingen gebruiken. Vervolgens chmod 777 de map waartoe u iedereen toegang wilt geven. Test vervolgens uw toegang.

Dan chmod 770 test de map opnieuw de toegang.

Als dit werkt zoals het hoort, voegt u acls één voor één weer toe.

Als ze geen uitvoeringsrechten nodig hebben, zou je het nog lager kunnen verlagen tot rw *, rx *, *** met chmod 660 mapnaam

Onthoud dat voor de periode waarin je geen acls en chmod 777 permissies hebt je map zal wijd openstaan voor iedereen, dus laat het niet zo achter.

Reacties

  • Niet iedereen, alleen mensen in een bepaalde groep. Ik zou de sticky bit van de groep in de directory kunnen instellen. Het probleem is dat gebruikers dan bestanden in de directory plaatsen, en de groep is correct, maar ze weten niet ‘ of ze vergeten de groepstoegang in te stellen. acls kan worden gebruikt om aan te geven dat een bepaalde groep toegang heeft tot de bestanden, onafhankelijk van hun groepsrechten. Dat is het perfecte antwoord. Het probleem is dat acls een masker hebben, en cp wist het acl-masker zodat het overeenkomt met de umask van de gebruiker, dus de effectieve machtigingen staan niet toe dat de bestanden worden gelezen.

Antwoord

Ik heb het geprobeerd. Het lijkt erop dat het umask de groepsmachtigingen in de war brengt, aangezien de groepsmachtigingen het masker van de ACL zijn. Het blokkeert alle groepen en ACLs.

Een oplossing is om de umask minder beperkend te maken.Om dit veilig te doen, moet u voor elke gebruiker een groep toevoegen en van deze groep de standaardgroep maken. (zie Waarom heeft elke gebruiker zijn eigen groep? ).

Dit is niet ideaal, aangezien er nog steeds een reden is voor verschillende umasks (g = rx en g = rwx). Deze strategie neemt alleen de noodzaak weg van groepsrechten.

Reacties

  • Ja, dat is wat ik had gedaan, ik heb in plaats daarvan gebruikersmaskers op 007 gezet van 077 als tijdelijke oplossing. Het is echter niet ´ t perfect, aangezien veel bestanden nog steeds mindere rechten hebben en erin worden gekopieerd. Wat ik hier hoopte te leren, was waarom cp zich zo gedraagt. Het lijkt mij dat dit het cp -p-gedrag zou moeten zijn. Ik had gehoopt dat iemand hier het zou kunnen uitleggen.

Antwoord

Alle antwoorden tot nu toe hebben advies gegeven over hoe om te gaan met het delen van bestanden via groepsmappen. Non heeft je hoofdvraag beantwoord, denk ik, die was: waarom gedraagt cp a b zich alsof cp -p a b is opgegeven? De man-pagina praat er inderdaad niet over, maar texinfo heeft de details. info coreutils "cp invocation" toont: 

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

Dus als de bestemming bestaat, wordt de inhoud vervangen, maar de modusbits zijn niet veranderd. Als de bestemming niet bestaat, worden modusbits uit de bron gekopieerd.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *