facl, setfacl, hakemiston jako, miksi cp laittaa alkuperäisen tiedoston oikeudet facl-maskiin? Pitäisikö ' t olla cp -p-käyttäytymistä?

Tämän järjestelmän käyttäjät ovat varovaisia ja heidän umaskejaan on asetettu hyvin yksityinen 0077. Käyttäjät haluavat kuitenkin ryhmäkohtaisia hakemistoja, joissa tiedostot voidaan kopioida jakamaan ne nimenomaisesti muiden ryhmän jäsenten kesken. Tällaisia jakohakemistoja voi olla useita, vaikka kukin niistä on nimenomaan ryhmää.

Ryhmän tahmean bitin asettaminen tietyssä hakemistossa käytettäväksi jakamiseen ei riitä. Vaikka tahmean bitin asettaminen aiheuttaa ryhmän omistajuuden oikeaksi hakemistoon sijoitetuissa tiedostoissa, mainittujen tiedostojen oikeudet asetetaan usein siten, että tiedostoja ei voida lukea tai muokata, eli niitä ei voida tosiasiallisesti jakaa. Ne näkyvät vain hakemistoluettelossa. Tämä johtuu siitä, että jotkut käyttäjät joko eivät ajattele tai eivät tiedä miten tehdä manuaalisesti vaaditut ryhmäoikeuksien mukautukset lukemisen ja kirjoittamisen sallimiseksi. Voimme antaa heille tauon, koska loppujen lopuksi käyttäjät eivät ole järjestelmänvalvojia. acls : lla voidaan määrittää, että tietyllä ryhmällä on pääsy jakohakemiston tiedostoihin riippumatta siitä, mitä ryhmän oikeudet olisivat olleet ilman acl-tiedostoja. Se on täydellinen ratkaisu, mutta se ei ole aivan toimiva.

Seuraavassa jaettu ryhmä on ”asiakas_portti” ja esimerkki käyttäjä, joka yrittää jakaa tiedostoa, on ”svw”. Kuten transkriptiosta voidaan nähdä, svw-käyttäjä on asiakas_portti-ryhmän jäsen. Hakemistoa, jossa jakaminen tapahtuu, kutsutaan myös nimellä ”asiakas_portti /”

Seuraava käyttää acls-tiedostoja. Asetin ryhmän oikeudet, oletusryhmän oikeudet, peitteen ja oletusmaskin. Se toimii hyvin hakemistossa luotuihin tiedostoihin tai kissan (tai tervan) kautta sinne siirrettyihin tiedostoihin, mutta outoa, ei tiedostoille, jotka ”cp” muokkaavat siellä:

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

Tämä osoittaa, että kun tiedosto luodaan hakemistoon, se saa oletusoikeudet ja on jaettavissa. Mutta käyttäjät eivät aina luo tiedostojaan siellä, yleensä he kopioivat ne siellä.

Mutta kopion tekeminen on sama asia, koska kopion tekeminen edellyttää ensin uuden tiedoston luomista. Puhumme tässä on tavallinen kopio, ei säilytyskäyttöoikeuksien kopiota. Se on sama kuin seuraava lomake, joka, btw toimii, ja kopioi tiedoston, joka on jaettavissa hakemistossa sen alkuperäisistä ryhmäoikeuksista riippumatta:

cat < data.in > shared/data.out 

toimii hienosti, myös tervan syöttäminen toimii, mutta muoto

cp data.in shared/data.out 

epäonnistuu. cat ed-tiedosto saa oletusmaskin ja oletusoikeudet. cp ed-tiedosto säilyttää käyttöoikeutensa acl-maskissa ja ryhmän käyttöoikeuksissa ikään kuin a cp -p (mutta se ei ollut ”t), ja näin ollen voimassa olevat oikeudet lukivat alkuperäisen tiedoston tavoin, eivät ne, joihin acl-tiedostot on asetettu.

Toisena kokeiluna suoritin tämän kokeilun ryhmä tahmea bitti, chmod g + rwxs, yhdessä fac ch: n kanssa ja saivat täsmälleen samat tulokset. Vaikka hakemistoluettelot ovat kauniimpia kaikkien jaettujen tiedostojen ryhmän omistajuuden vuoksi. Juoksin sen myös niin, että vain ryhmän tahmea bitti oli asetettu ilman setfaclia. Sillä oli sama tulos kopioiduille tiedostoille (joten facls näyttää melko hyödyttömältä hakemistolle, johon tiedostot kopioidaan jaettavaksi).

Millä perusteella ja millä perusteilla linux-pikselit erottavat tiedostot toisistaan luodaanko tietoja? Miksi pakottaa cp säilyttämään käyttöoikeudet, kun sitä ei ole käsketty tekemään? Mikä syy oikeuttaisi hämmennyksen, joka aiheutuu tästä erosta kissan ja tervaputken kautta kulkevan putkiston välillä, mutta cp ei toimi? Puuttuuko minulta maaginen loitsu, joka tekisi tämän eron haihtuu?

Onko tämä yhteenveto oikea: facls antaa sinun voittaa omistusoikeuden tiedostojen jakamiseen, se tekee käyttöoikeuksista sallivammat kuin umask, kun tiedostoja luodaan, paitsi jos luominen johtuu cp-komennosta ja hyvästä syystä, koska … koska miksi?

Kommentit

• Mitä käyttöjärjestelmää (linux distro ja versio) ja mitä tiedostojärjestelmää käytät? Olisiko hyvä saada ihmiset käyttämään cat, ehkä tähän tarkoitukseen tarkoitetun erillisen shell-skriptin kautta?
• Aiotko, että kukaan ryhmän jäsenistä voi muokata tai poistaa mitään tiedostoa, vai pitäisikö vain luojalla olla tällaiset oikeudet? Toisin sanoen vain lukuoikeudet (ja ehkä suorittaa käyttäjille.
• Debian 10. Koska tiedostojen luominen toimii, ’ veen kopioita tervan kautta. I ’ ll paketin, joka on projekt_cp-komento kansiossa / usr / local / bin. Jos käyttäjän on kuitenkin käytettävä erityistä kopiointikomentoa, voisi vain mennä ryhmän tahmean bitin kanssa ilman kasvoja ja asettaa käyttöoikeudet. Haluan tietää, kuinka asettaa acls niin, että kissan terva ja cp toimivat.’ Ajattelen, että cp: llä varustetuissa acl-tiedostoissa on ongelma, koska he tekevät cp -p -käyttäytymistä cp-käyttäytymisen sijaan. ’ Odotan innolla kuulemistasi käyttöoikeusasiantuntijoilta.
• Ryhmäjako on toistuva ongelma muunnelmilla, kuten huomautat. Tässä tapauksessa ohjelmistokehittäjillä on pääsy testijulkaisuhakemistoon. Heidän on tylsää. He voivat työskennellä kyseisessä hakemistossa, työntää, vetää, asentaa virtuaaliseen ympäristöön jne. Ongelma syntyy, kun he kopioivat asioita toiselta alueelta, jolla he ovat työskennelleet, eikä heidän umaskeilleen ole asetettu ryhmäoikeuksia. Se on heille hämmentävää, koska tiedostojen luominen ja tervalla kopiointi toimii hyvin. On myös hauskaa, että minun on annettava heille kopio käsikirjoituksesta, joka tekee vain sen, mitä cp tekee. ’ acls ’ ne ovat taikuutta, sanon LOL
• En ole käyttöoikeuksien asiantuntija, mutta toivon, että kysymykseni ja vastauksesi voivat auttaa asiantuntijoita antamaan sinulle asiaankuuluvia vastauksia.