facl, setfacl, directory share, miért teszi a cp az eredeti fájlengedélyeket a facl maszkba? Nem kellene, hogy ' t ez cp -p viselkedés legyen?

A rendszer felhasználói a körültekintőek, és az umákjaik a nagyon privát 0077-re vannak állítva. A felhasználók azonban szeretnének csoporthoz tartozó könyvtárakat, ahol a fájlok másolhatók, hogy kifejezetten megosszák őket a többi csoporttag között. Több ilyen megosztási könyvtár lehet, bár mindegyik egy csoportra jellemző.

A csoport ragadós bitjének beállítása egy adott könyvtárban a megosztáshoz nem elegendő. Bár a ragacsos bit beállítása miatt a csoport tulajdonjoga helyes a könyvtárba helyezett fájlokon, az említett fájlok engedélyeit gyakran úgy állítják be, hogy a fájlokat nem lehet elolvasni vagy szerkeszteni, vagyis valójában nem lehet megosztani. Csak megjelennek a könyvtárlistában. Ennek oka, hogy egyes felhasználók vagy nem gondolkodnak, vagy nem tudják, hogyan végezzék el manuálisan a szükséges csoportengedély-beállításokat az olvasás és az írás engedélyezéséhez. Adhatunk nekik egy kis szünetet ebben, mert a felhasználók mégsem adminok. Az acls segítségével megadható, hogy egy adott csoportnak hozzáférése van a megosztási könyvtár fájljaihoz, függetlenül attól, hogy a csoport engedélyei mi lettek volna acls nélkül. Ez a tökéletes megoldás, de nem egészen működik.

A következőkben a megosztott csoport neve “customer_gateway”, a fájlt megosztani próbáló felhasználó pedig “svw”. Amint az az átiratból látható, az svw felhasználó a customer_gateway csoport tagja. A megosztást végző könyvtárat más néven “customer_gateway /”

A következők acls-t használnak. Beállítottam a csoportengedélyeket, az alapértelmezett csoportengedélyeket, a maszkot és az alapértelmezett maszkot. Jól működik a könyvtárban létrehozott fájlok, vagy a cat (vagy tar) útján oda áthelyezett fájlok esetében, de furcsa módon nem azoknál a fájloknál, amelyeket “cp” szerkesztett:

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

Ez azt mutatja, hogy amikor egy fájlt létrehoznak a könyvtárban, akkor az megkapja az alapértelmezett engedélyeket és megosztható. De a felhasználók nem mindig készítik ott a fájljaikat, általában ott cp-k.

De a másolat készítése ugyanaz, mert másoláshoz először létre kell hoznunk egy új fájlt. itt egy sima másolat, nem az engedélyek megőrzése. Ez megegyezik a következő űrlappal, amely a btw működik, és átmásol egy fájlt, amely az eredeti csoportengedélyektől függetlenül megosztható lesz a könyvtárban:

cat < data.in > shared/data.out 

remekül működik, a kátrány átvezetője is működik, de a

cp data.in shared/data.out 

űrlap nem működik. A cat ed fájl megkapja az alapértelmezett maszkot és alapértelmezett jogosultságokat. Az a cp -p (de nem volt “t”), és így a tényleges engedélyek az eredeti fájlhoz hasonlóan olvashatók, nem pedig az, amire az acls-t beállították.

Második próbálkozásként futtattam ezt a kísérletet a csoportos ragacsos bit, chmod g + rwxs, valamint a fac ch és pontosan ugyanazokat az eredményeket kapta. Bár a címjegyzékek szebbek, mivel az összes megosztott fájl esetében megjelenik a csoport tulajdonjoga. Azt is futtattam, hogy csak a csoport ragadós bitje volt beállítva, a setfacl nélkül. Ugyanazt az eredményt kapta a másolt fájlok esetében is (tehát a parancsfájlok meglehetősen használhatatlannak tűnnek egy olyan könyvtár megosztásához, ahová a fájlokat másolják).

Milyen alapon és milyen indoklással különböztetik meg a linux-os parancsfájlok a fájlok különböző formáit adatok létrehozása? Miért kényszerítjük a cp-t az engedélyek megőrzésére, ha ezt még nem mondták meg neki? Mi indokolná azt a zűrzavart, amelyet a macska és a kátránymunkán keresztüli csövek közötti különbségtétel okoz, de a cp nem működik? Hiányzik egy varázsigézet, amely ezt a különbséget tenné elpárolog?

Helyes ez az összefoglaló: a facls lehetővé teszi a fájlok megosztása érdekében a tulajdonjog leküzdését, a fájlok “létrehozásakor” megengedőbbé teszi az engedélyeket, mint az umask, kivéve, ha a létrehozás a cp parancsnak és jó okból, mert … mert miért?

Megjegyzések

• Milyen operációs rendszert (linux disztribúció és verzió) és melyik fájlrendszert használod? Helyes lenne az embereket arra késztetni, hogy használják a cat -t, esetleg erre a célra szolgáló külön shellscript segítségével?
• Szándékában áll, hogy a csoport bármely felhasználója módosíthassa vagy törölhesse bármilyen fájlt, vagy csak az alkotónak kell ilyen engedélyekkel rendelkeznie? Más szavakkal, csak az o engedélyeit olvassa el (és talán végrehajthatja)
• Debian 10. Mivel a fájl létrehozása működik, ‘ átmásoltam a másolatokat a taron keresztül. Én ‘ csomagolom ezt proj_cp parancsként az / usr / local / bin fájlban. Ha azonban a felhasználónak speciális másolási parancsot kell használnia, akkor egyszerűen a csoport ragacsos bitjével lehet menni a karakterek nélkül, és megadhatja az engedélyeket. Szeretném tudni, hogyan állítsuk be az acl-eket úgy, hogy a macska tar és cp működjenek.’ Úgy gondolom, hogy probléma van a cp-vel rendelkező acl-kkel, mivel a cp-viselkedés helyett a cp -p viselkedést végzik. ‘ várom, hogy meghallgassam az engedélyek szakértőit.
• A csoportmegosztás visszatérő probléma a variációkkal, amint rámutat. Ebben az esetben a szoftverfejlesztők hozzáférnek a tesztkiadási könyvtárhoz. Az övék, akiket elcsesznek. Dolgozhatnak abban a könyvtárban, nyomhatnak, húzhatnak, telepíthetnek a virtuális környezetbe stb. A probléma akkor jelentkezik, amikor más dolgokat másolnak be egy másik területről, ahol dolgoztak, és az umákjaik nincsenek csoportengedélyekkel beállítva. Számukra zavarba ejtő, mert a fájlok létrehozása és a tar által történő másolás jól működik. Az is furcsa, hogy át kell adnom nekik egy olyan szkriptet, amely csak azt csinálja, amit a cp. ‘ acls ‘ ezek varázslatosak, azt mondom, LOL
• nem vagyok jogosultsági szakértő, de remélem, hogy a kérdéseim és az Ön válaszai segíthetnek a szakértőknek releváns válaszok megadásában.