Fayl egaligi: UID, GID, chown va chgrp

ls -l fayl egasini ali:developers ko'rinishida chiqaradi. Lekin kernel ruxsatlarni hech qachon shu matnga qarab tekshirmaydi — u inode’da saqlangan UID va GID raqamlaridan foydalanadi. Bu farq zaxira nusxa boshqa serverda tiklanganda, konteyner nom o'rniga notanish raqam ko'rsatganda yoki endi mavjud bo'lmagan hisobdan fayllar qolib ketganda juda muhim bo'ladi.

Oldingi maqola — Fayl ruxsatlari — kernel jarayon uchun bitta ruxsat sinfini (egasi, guruh yoki boshqalar) qanday tanlashini ko'rsatdi. Bu maqolada esa o'sha "egasi" va "guruh" aslida qayerdan kelishini ko'ramiz: egalik inode’da saqlanadigan ikkita raqam. Quyida ls, stat, id va getent ni birgalikda o'qishni; chown, chgrp, --reference va --from bilan nazorat ostidagi o'zgarishlar kiritishni; egalik hard link’da symbolic link’dagidan qanday farq qilishini o'rganamiz. Shuningdek, ommaviy chown amalini maqsadni tekshirish, mount’larni hisobga olish, symlink auditi va rollback rejasi bilan xavfsiz chegaralashni ko'rib chiqamiz.

Egalik nom sifatida emas, raqam sifatida saqlanadi

Boshqa metama’lumotlar qatori har bir inode ikkita identifikatorni saqlaydi:

• UID (user ID): fayl egasining raqamli identifikatori.
• GID (group ID): fayl guruhining raqamli identifikatori.

Foydalanuvchi nomi — UID uchun odam o'qiy oladigan yorliq, guruh nomi esa GID uchun. UID 1001 bir hostda ali, boshqasida deploy bo'lishi mumkin. Faylni ikkinchi hostga ko'chirish uning ko'zlangan ma’nosini avtomatik saqlamaydi — u bilan birga faqat xom raqamli metama’lumotlar ko'chadi.

stat -c 'mode=%A owner=%U uid=%u group=%G gid=%g path=%n' -- <file_path>

Namunaviy natija:

mode=-rw-r----- owner=root uid=0 group=inventory gid=992 path=/srv/inventory/app.conf

owner=root uid=0 inode’dagi UID 0 shu hostning hisoblar bazasida root nomiga mos kelishini bildiradi. group=inventory gid=992 guruh uchun xuddi shu bog'liqlikni ko'rsatadi. Sizning tizimingizdagi UID va GID lar boshqacha bo'ladi.

ls -ln nomlarni aniqlamasdan xom raqamlarni chiqaradi:

ls -ln -- <file_path>

Bu zaxira nusxada, NFS da yoki konteyner ichidagi nomuvofiqlikni topishda foydali. Lekin avtomatlashtirishda ls matnini tahlil qilishdan ko'ra stat -c '%u:%g' kabi aniq formatni afzal ko'ring.

Nomlar qayerdan keladi?

Name Service Switch (NSS) /etc/nsswitch.conf orqali hisob ma’lumotlarini qaysi manbalardan qidirishni hal qiladi. Bu manba faqat /etc/passwd va /etc/group bilan cheklanishi shart emas — LDAP yoki boshqa katalog xizmati ham ishtirok etishi mumkin. Shuning uchun faqat lokal faylni grep qilish to'liq tekshiruv emas.

getent passwd <username>
getent group <group>
id <username>

Masalan:

inventory:x:992:992:Inventory service:/var/lib/inventory:/usr/sbin/nologin
inventory:x:992:
uid=992(inventory) gid=992(inventory) groups=992(inventory)

Birinchi qator foydalanuvchining UID va asosiy GID ini, ikkinchisi guruhning GID ini, id esa hisobning asosiy va qo'shimcha guruhlarini ko'rsatadi. Agar getent hech narsa qaytarmasa, darhol yangi hisob yaratish kerak yoki raqamli chown kerak degan xulosaga kelmang — katalog xizmatini, NSS sozlamasini va tarmoq holatini ham tekshiring.

Laboratoriyani tayyorlash

Bu laboratoriya faqat joriy foydalanuvchining uy katalogi ichida ishlaydi va sudo talab qilmaydi.

mkdir -p ~/lab/ownership/data
printf '%s\n' 'ownership-lab' > ~/lab/ownership/data/report.txt
ln ~/lab/ownership/data/report.txt ~/lab/ownership/report-hardlink.txt
ln -s data/report.txt ~/lab/ownership/report-symlink.txt
stat -c '%F inode=%i owner=%U(%u) group=%G(%g) path=%n' \
    ~/lab/ownership/data/report.txt \
    ~/lab/ownership/report-hardlink.txt \
    ~/lab/ownership/report-symlink.txt

Namunaviy natija:

regular file inode=183511 owner=ali(1000) group=ali(1000) path=/home/ali/lab/ownership/data/report.txt
regular file inode=183511 owner=ali(1000) group=ali(1000) path=/home/ali/lab/ownership/report-hardlink.txt
symbolic link inode=183514 owner=ali(1000) group=ali(1000) path=/home/ali/lab/ownership/report-symlink.txt

Sizning uy katalogingiz yo'li, nomlar, ID lar va inode raqamlari boshqacha bo'ladi. Birinchi ikki yo'l bitta inode raqamiga ega bo'lishi, symlink’niki esa boshqa bo'lishi kerak.

Yangi obyektning egasi va guruhi qanday tanlanadi

Yangi faylning egasi odatda uni yaratgan jarayonning fayl tizimi UID i (filesystem UID) bo'ladi. Kundalik dasturlarda u effective UID bilan bir xil. sudo touch file va oddiy touch file aynan yaratayotgan jarayonning identifikatori tufayli turli egali fayllar yaratadi.

Yangi obyektning guruhi uchun ikki asosiy holat bor:

1. sukut bo'yicha jarayonning fayl tizimi GID i ishlatiladi — amalda odatda foydalanuvchining asosiy guruhi;
2. agar ota katalogda set-group-ID (setgid) biti yoqilgan bo'lsa, yangi obyekt uning o'rniga ota katalogning guruhini meros qilib oladi.

Fayl tizimi turi va grpid/bsdgroups kabi mount parametrlari ham bu tanlovga ta’sir qilishi mumkin. Taxmin qilish o'rniga haqiqiy muhitni tekshiring:

id
stat -c 'mode=%A (%a) owner=%U:%G path=%n' -- <parent_directory>
findmnt -T <parent_directory> -o TARGET,FSTYPE,OPTIONS

Nega umumiy katalogga setgid kerak?

Faraz qilaylik, /srv/reports root:reporters ga tegishli va reporters guruhidagi bir nechta foydalanuvchi u yerda fayl yaratadi. setgid bo'lmasa, yangi fayl har bir foydalanuvchining o'z asosiy guruhiga tushishi mumkin va umumiy bo'lishi kerak bo'lgan katalogda turli guruhlarga tegishli fayllar aralashib ketadi.

Avval guruh va joriy holatni tekshiring:

getent group reporters
id <username>
stat -c '%A %a %U:%G %n' -- /srv/reports
findmnt -T /srv/reports -o TARGET,FSTYPE,OPTIONS

So'ng, agar tashkilot siyosati katalogni umumiy qilishni talab qilsa:

sudo chgrp reporters /srv/reports
sudo chmod 2770 /srv/reports
stat -c '%A %a %U:%G %n' -- /srv/reports

2 — katalogning setgid biti. 2770 bilan yangi obyektlar reporters guruhini meros qilib oladi, yangi ichki kataloglar esa odatda setgid bitini ham meros qilib oladi. Bu buyruq katalog ichidagi mavjud fayllarning guruhini o'zgartirmaydi.

Egalikni umask bilan adashtirmang: egalik obyekt qaysi UID/GID ga tegishli ekanini hal qiladi, umask esa yaratish paytida qaysi oddiy ruxsat bitlari tozalanishini hal qiladi.

chown va chgrp sintaksisi

GNU Coreutils’dagi asosiy sintaksis:

chown [OPTION]... [OWNER][:[GROUP]] FILE...
chown [OPTION]... --reference=REF_FILE FILE...
chgrp [OPTION]... GROUP FILE...

Har bir shakl nima qiladi:

Ba’zi tizimlarda eski owner.group ajratuvchisi uchraydi, lekin ko'chma skriptda owner:group deb yozish kerak. Egasi/guruh ko'rsatkichi va fayl yo'li orasida bo'sh joy bo'ladi — ali : developers kabi shakl noto'g'ri.

Kim nimani o'zgartira oladi?

Linux’da fayl egasini boshqa foydalanuvchiga o'zgartirish odatda CAP_CHOWN imkoniyatini (capability) talab qiladi, shuning uchun administratorlar sudo chown ... dan foydalanadi. Oddiy fayl egasi esa guruhni faqat chaqirayotgan jarayon a’zo bo'lgan guruhlardan biriga o'zgartira oladi:

id -Gn
chgrp <member_group> <your_own_file>

Yangi guruhga endigina qo'shilgan foydalanuvchi bu a’zolikni allaqachon ochiq turgan shell jarayonida darhol ko'rmasligi mumkin. Agar id yangi yozuvni ko'rsatsa-yu, joriy sessiyadagi id -Gn eski holatni ko'rsatsa, yangi login sessiyasini oching — muammoni sudo chown bilan yamab qo'ymang.

Bitta faylni nazorat ostida o'zgartirish

Production’da buyruqni bajarishdan oldin nomlarni, maqsadni va oldingi holatni isbotlang:

getent passwd <new_owner>
getent group <new_group>
stat -c '%A %a %U(%u):%G(%g) %n' -- <absolute_file_path>
namei -l <absolute_file_path>

So'ng:

sudo chown <new_owner>:<new_group> -- <absolute_file_path>
stat -c '%A %a %U(%u):%G(%g) %n' -- <absolute_file_path>

Egalikni boshqa UID/GID ga berish uchun sudo kerak. -- undan keyingi hamma narsa opsiya emas, fayl nomi ekanini bildiradi — bu, ayniqsa, nom tasodifan - bilan boshlanganda muhim.

Bir nechta fayl bitta namuna faylning egaligiga mos kelishi kerak bo'lsa:

stat -c '%U:%G %n' -- <reference_file> <target_file>
sudo chown --reference=<reference_file> -- <target_file>
stat -c '%U:%G %n' -- <reference_file> <target_file>

--reference raqamlarni qo'lda noto'g'ri ko'chirish xavfini kamaytiradi, lekin namuna faylning o'zi to'g'ri ekanini baribir avval tekshirish kerak.

--from: kutilmagan obyektlarni o'tkazib yuborish

GNU chown ning --from=<old_owner>:<old_group> opsiyasi egalikni faqat obyektning joriy egaligi berilgan qiymatlarga aynan mos kelsagina o'zgartiradi:

sudo chown --from=<old_owner>:<old_group> \
    <new_owner>:<new_group> -- <absolute_file_path>

Bu faqat o'qiydigan stat tekshiruvi va haqiqiy chown o'rtasida holat o'zgarib qolishi mumkin bo'lgan vaqt oralig'ini toraytiradi. Buyruqning chiqish holati 0 bo'lsa ham, --from ga mos kelmagan fayl jimgina o'tkazib yuborilgan bo'lishi mumkin — natijani doim stat bilan tasdiqlang.

Hard link va symbolic link’larda egalik

Hard link alohida nusxa emas — u bitta inode’ning yana bir nomi. Laboratoriyadagi ikki hard link’dan biriga chgrp qilish ikkinchi nomning natijasini ham o'zgartiradi:

chgrp "$(id -gn)" -- ~/lab/ownership/report-hardlink.txt
stat -c 'inode=%i %U:%G %n' \
    ~/lab/ownership/data/report.txt \
    ~/lab/ownership/report-hardlink.txt

Ikkala qatorda ham bir xil inode va egalik ko'rinadi, chunki chgrp katalog yozuvining o'zini emas, u ishora qilayotgan inode’ni o'zgartirdi.

Symbolic link’ning o'z inode’i va egaligi bor, lekin oddiy chown link odatda link ortidan borib, uning o'rniga maqsad ustida ishlaydi. Ikki obyektni alohida ko'ring:

stat -c 'link:   %F %U:%G %n' -- ~/lab/ownership/report-symlink.txt
stat -Lc 'target: %F %U:%G %n' -- ~/lab/ownership/report-symlink.txt

GNU chown -h (yoki --no-dereference) maqsad o'rniga symlink’ning o'zi ustida ishlaydi:

chown -h "$(id -un):$(id -gn)" -- ~/lab/ownership/report-symlink.txt

Ko'pchilik Linux tizimlarida symlink’ning o'z rejim bitlari kirish huquqini boshqarmaydi, lekin uning egaligi sticky bit bo'yicha o'chirish qoidalari yoki himoyalangan symlink (protected symlink) siyosati uchun ahamiyatli bo'lishi mumkin.

Rekursiv o'zgarishni xavfsiz chegaralash

chown -R daraxt ichidagi har bir obyektga tegadi va uning --dry-run rejimi yo'q. Shuning uchun oldindan ko'rish alohida, faqat o'qiydigan buyruq bilan bajariladi.

Masalan, hali ham eski ci-runner:ci-runner ga tegishli obyektlarni topish:

find <target_directory> -xdev \
    -user ci-runner -group ci-runner \
    -printf '%y %m %u:%g %p\n'

-xdev boshqa mount’ga o'tib ketishning oldini oladi. Agar natijadagi yo'llar, obyekt turlari yoki ularning soni kutilganidek bo'lmasa, shu yerda to'xtang. Symlink maqsadlarini, mount daraxtini va maqsad katalogning o'zini ham tekshiring:

realpath -- <target_directory>
stat -c '%F %A %U:%G %n' -- <target_directory>
findmnt -R -T <target_directory>
find <target_directory> -xdev -type l -printf '%p -> %l\n'

Afzal rollback yo'li — snapshot yoki konfiguratsiyani boshqarish vositasi. Agar ACL vositalari mavjud bo'lsa, egalik, rejim va ACL’larni matnli zaxira nusxa sifatida saqlash mumkin:

backup_file=$(sudo mktemp /root/ownership.before.XXXXXX)
sudo getfacl -Rp <target_directory> | sudo tee "$backup_file" >/dev/null
sudo chmod 0600 "$backup_file"
printf '%s\n' "$backup_file"

<target_directory> ni faqat yuqoridagi tekshiruvlardan o'tgan absolyut yo'l bilan almashtiring. Zaxira nusxa yo'lini o'zgarishlar qaydingizga yozib qo'ying.

GNU muhitida bitta fayl tizimi bilan chegaralangan va eski egalikni qayta tekshiradigan shakl:

sudo find <target_directory> -xdev \
    -user ci-runner -group ci-runner \
    -exec chown -h --from=ci-runner:ci-runner appuser:appgroup -- {} +

Bu buyruq ko'plab obyektlarni o'zgartiradi. Uni faqat test nusxasida tekshirilgan, zaxira nusxa olingan va yuqoridagi oldindan ko'rish ro'yxati ko'rib chiqilganidan keyingina ishga tushiring. find sukut bo'yicha symlink’lar ortidan bormaydi, chown -h esa link’ning o'zi ustida ishlaydi; --from esa oldingi find tekshiruvidan keyin egaligi allaqachon o'zgargan obyektga qayta tegmaslikka yordam beradi.

Tekshirish:

find <target_directory> -xdev \
    \( ! -user appuser -o ! -group appgroup \) \
    -printf 'unexpected %u:%g %p\n'

Bu tekshiruv faqat har bir obyekt oxirida aynan appuser:appgroup bo'lishi kerak degan siyosat ostida ma’noga ega. Agar turli ichki kataloglar turli siyosatga amal qilsa, har birini o'z sharti bilan tekshiring.

Rollback:

sudo setfacl --restore="$backup_file"

So'ng tiklangan holatni stat, find va xizmat hisobi ostidagi yon ta’sirsiz haqiqiy tekshiruv bilan tasdiqlang. Agar zaxira nusxa olinmagan, u to'liq bo'lmasa yoki zaxira nusxadan keyin daraxt o'zgargan bo'lsa, bu buyruqni taxmin bilan ishga tushirmang.

Egalikni o'zgartirishning yon ta’sirlari

chown ls -l dagi faqat ikki ustunni o'zgartiradi deb hisoblash xavfli. Linux’da egasi yoki guruh o'zgarganda:

• bajariladigan faylning set-user-ID va set-group-ID bitlari tozalanishi mumkin;
• faylga biriktirilgan file capabilities tozalanadi;
• jarayon qaysi u/g/o ruxsat sinfiga tushishi o'zgarishi mumkin;
• kvotalar, NFS UID moslashtirish, konteyner user namespace’i yoki idmapped mount hostning o'zi ko'rsatgandan boshqacha natija ko'rsatishi mumkin.

Bajariladigan yoki capability’ga ega faylning egaligini o'zgartirishdan oldin va keyin kamida quyidagilarni tekshiring:

stat -c '%A %a %U:%G %n' -- <executable_path>
getcap -- <executable_path>

getcap odatda libcap2-bin (Ubuntu/Debian) yoki libcap (RHEL oilasi) paketidan keladi. Bo'sh natija shunchaki hech qanday capability o'rnatilmaganini bildirishi mumkin. Production’da xavfsizlik atributini qo'lda tiklashdan oldin kutilgan holatni paket menejeri, deploy manifesti yoki konfiguratsiyani boshqarish tizimida tekshiring.

Nusxalash va ko'chirishda nima bo'ladi?

Oddiy cp source dest manzilda yangi inode yaratadi va uning egaligi odatda manbadan emas, nusxalayotgan jarayondan olinadi. cp -a yoki --preserve=ownership metama’lumotlarni saqlashga urinadi, lekin buning uchun yetarli huquq va fayl tizimi qo'llab-quvvatlashi kerak. Bitta fayl tizimi ichidagi mv odatda shu inode’ni qayta nomlaydi, shuning uchun egalik saqlanadi.

Zaxiradan tiklash yoki deploy "muvaffaqiyatli" tugagani egalik to'g'ri chiqdi degani emas. Tiklashni baholashda fayl mazmuni bilan birga stat, ACL’lar va kerak bo'lsa capabilities ni ham tekshiring.

Amaliy vaziyat: reliz noto'g'ri hisobga tegishli

CI tizimi /srv/inventory/releases/2026-07-24 relizini ci-runner:ci-runner egaligida qoldirgan. inventory.service esa inventory hisobi ostida ishlaydi. Siyosatga ko'ra reliz kodi root:inventory ga tegishli bo'lishi, xizmat uni o'qiy olishi, lekin unga yoza olmasligi kerak.

1. Jarayon va siyosatni aniqlang

systemctl show -p User -p Group inventory.service
getent passwd inventory
getent group inventory
id inventory

Namunaviy, tegishli parcha:

User=inventory
Group=inventory
uid=992(inventory) gid=992(inventory) groups=992(inventory)

Unit’dagi bo'sh User= tizim xizmati root sifatida ishlashini anglatishi mumkin; jarayon ishlab turgan bo'lsa, ps -o pid,user,group,comm -C <process_name> bilan ham tasdiqlang.

2. Daraxtni o'zgartirmasdan audit qiling

release=/srv/inventory/releases/2026-07-24
realpath -- "$release"
findmnt -R -T "$release"
namei -l "$release"
sudo find "$release" -xdev -printf '%y %m %u:%g %p\n'
sudo find "$release" -xdev -type l -printf '%p -> %l\n'

release o'zgaruvchisi faqat joriy shell sessiyasida yashaydi. realpath ko'zlangan absolyut yo'lni tasdiqlaydi, findmnt ichki mount’larni ko'rsatadi, namei ota kataloglarni qamraydi, find esa egalik va symlink’larni ko'rsatadi. Natija faqat shu bitta reliz daraxtini qamrab olishi kerak.

3. Rollback’ni tayyorlang

VM yoki saqlash tizimi snapshot’ini oling. Bunga qo'shimcha:

backup_file=$(sudo mktemp /root/inventory-release.acl.before.XXXXXX)
sudo getfacl -Rp "$release" | sudo tee "$backup_file" >/dev/null
sudo chmod 0600 "$backup_file"
printf '%s\n' "$backup_file"

Snapshot va zaxira nusxa reliz yaratilgandan beri kiritilgan barcha o'zgarishlarni qamrab olishi kerak. Agar faol deploy hali davom etayotgan bo'lsa, uni to'xtatmasdan ro'yxatni olish nomuvofiq holat suratini berishi mumkin.

4. Faqat kutilgan eski egalikni o'zgartiring

Qaysi obyektlarga ta’sir qilishini yana bir bor aniq ko'rib chiqing:

sudo find "$release" -xdev \
    -user ci-runner -group ci-runner \
    -printf '%y %m %u:%g %p\n'

Tekshirilgan test nusxasida natija to'g'ri ko'ringach:

sudo find "$release" -xdev \
    -user ci-runner -group ci-runner \
    -exec chown -h --from=ci-runner:ci-runner root:inventory -- {} +

Bu yondashuv ataylab boshqa guruhga berilgan obyektlarga tegmaydi. Agar siyosat reliz ichidagi har bir obyekt root:inventory bo'lishini talab qilsa, qolgan istisnolar keyingi tekshiruvda ko'rinadi.

5. Xizmat hisobi bilan tekshiring

sudo find "$release" -xdev \
    \( ! -user root -o ! -group inventory \) \
    -printf 'unexpected %u:%g %p\n'
sudo -u inventory -- test -r "$release/app.conf"
echo $?
sudo -u inventory -- test ! -w "$release/app.conf"
echo $?

Birinchi find hech narsa qaytarmasligi, ikkala echo esa 0 ni chiqarishi kerak: xizmat konfiguratsiyani o'qiy oladi, lekin unga yoza olmaydi. Rejim va ota katalog ruxsatlari ham siyosatga mos bo'lishi kerak — egalikning o'zi kirish huquqini kafolatlamaydi.

6. Rollback

Agar xizmat tekshiruvi yoki monitoring kutilmagan natija ko'rsatsa:

sudo setfacl --restore="$backup_file"
sudo find "$release" -xdev -printf '%y %m %u:%g %p\n'

So'ng xizmatni aynan inventory hisobi ostida qayta sinab ko'ring. Agar production’da snapshot yoki konfiguratsiyani boshqarish orqali rollback mavjud va tekshirilgan bo'lsa, o'sha yo'lni afzal ko'ring.

Keng tarqalgan xatolar

chmod va chown ni bir xil ish deb hisoblash

chmod ruxsat bitlarini, chown esa UID/GID ni o'zgartiradi. Permission denied chiqqanda ikkalasini ham ko'r-ko'rona kengaytirish ko'zlangan siyosatni buzadi. Avval jarayon qaysi hisob ostida ishlashini va aslida qaysi ruxsat sinfiga tushishini aniqlang.

Xizmat kodini xizmatning o'ziga topshirish

Agar xizmatga faylni faqat o'qish kerak bo'lsa, uning bajariladigan fayli va konfiguratsiyasini root:<service_group> egaligida saqlash ko'pincha xavfsizroq. Buzilgan xizmat jarayoni o'z kodi yoki konfiguratsiyasini ustidan yoza olmasligi kerak. Runtime ma’lumotlari uchun /var/lib/<service> kabi alohida, yozish mumkin bo'lgan katalog to'g'ri joy.

Yangi fayl ota katalog egasini meros qilib oladi deb o'ylash

Yangi faylning egasi ota katalog egasidan emas, uni yaratgan jarayondan olinadi. setgid katalog faqat guruh merosini boshqaradi. Agar ega meros qilib olinayotgandek tuyulsa, yaratayotgan jarayon aslida qaysi hisob ostida ishlashini qayta tekshiring.

Raqamli ID ni nomsiz ko'r-ko'rona ishlatish

chown 1001:1001 boshqa hostda butunlay boshqa hisobga tegishli bo'lishi mumkin. Avval moslikni getent passwd 1001 va getent group 1001 bilan tekshiring. Bir xil raqam konteyner va uning hosti o'rtasida turli xavfsizlik identifikatorini ham bildirishi mumkin.

chown -R ni butun ilova ildiziga qo'llash

Reliz kodi, maxfiy ma’lumotlar, socket’lar, yuklangan fayllar va loglar har biri boshqa egalik siyosatini talab qilishi mumkin. Bitta rekursiv buyruq bu chegaralarni o'chirib yuboradi. Ichki kataloglarni vazifasiga qarab ajrating va o'zgarishni ma’lum oldingi holat bilan cheklash uchun --from dan foydalaning.

Symlink aslida nimaga ishora qilishini tekshirmaslik

Oddiy chown symlink ortidan uning maqsadiga boradi; chown -h esa link’ning o'zi ustida ishlaydi. Rekursiv aylanishda -H, -L va -P natijani o'zgartiradi. GNU chown -R sukut bo'yicha -P dan foydalanadi, lekin production buyrug'i baribir symlink siyosatini taxmin qilmasdan aniq tekshirishi kerak.

Chiqish holati 0 hammasi o'zgardi degani deb o'ylash

--from ga mos kelmagan fayl jimgina o'tkazib yuborilishi mumkin. Turli ichki daraxtlar bitta umumiy tekshiruvga sig'maydigan turli siyosatlarni ham talab qilishi mumkin. O'zgarishdan keyin yakuniy holatni mustaqil stat yoki find sharti bilan isbotlang.

Bajariladigan fayl capabilities va maxsus bitlarini unutish

Egalikni o'zgartirish setuid/setgid bitlarini yoki file capabilities ni tozalashi mumkin. Imtiyozli bajariladigan faylga chown qilishdan oldin paket/deploy talabini stat va getcap natijalari bilan birga qayd eting.

Mashqlar

1. Uchta laboratoriya yo'lini stat bilan ham nomli, ham raqamli shaklda chiqaring. Har bir UID/GID ni getent bilan nomga qaytarib aniqlang.
2. report.txt va report-hardlink.txt ning inode raqamlarini solishtiring. Bitta nom orqali chgrp "$(id -gn)" ni bajaring va nima uchun xuddi shu natija ikkinchi nom orqali ham ko'rinishini tushuntiring.
3. Symlink uchun stat va stat -L natijalarini solishtiring. Qaysi biri link’ning o'z inode’ini, qaysi biri maqsadnikini ko'rsatishini qayd eting.
4. A’zo bo'lgan guruhlaringizni id -Gn bilan toping. Agar ular bittadan ko'p bo'lsa, test faylni chgrp bilan qo'shimcha guruhga o'tkazing, so'ng asosiy guruhingizga qaytaring. Egalikni boshqa foydalanuvchiga berishga urinmang.
5. find -xdev -printf '%y %m %u:%g %p\n' asosida ~/lab/ownership uchun audit hisobotini tuzing. Taxminiy production tuzatishi uchun qaysi obyektlar o'zgarishini, qanday zaxira nusxa olinishini va qaysi buyruq rollback’ni bajarishini yozing — haqiqiy tizim katalogini o'zgartirmang.

Mashqni bajardim deyish uchun: javoblaringizda faqat sukut bo'yicha ko'rsatilgan nomni emas, ko'rinadigan nomni inode’dagi UID/GID, NSS moslashuvi, jarayon identifikatori va hard link/symlink xatti-harakati bilan bog'lang.

Laboratoriyani tugatganingizda maqsadni faqat o'qish orqali ko'rib chiqing:

find ~/lab/ownership -xdev -maxdepth 3 -printf '%y %m %u:%g %p\n'

Natijada faqat ~/lab/ownership test daraxti ko'rinsagina:

rm -rI -- ~/lab/ownership

Manbalar

• Linux man-pages: inode(7): https://man7.org/linux/man-pages/man7/inode.7.html
• Linux man-pages: chown(2): https://man7.org/linux/man-pages/man2/chown.2.html
• Linux man-pages: credentials(7): https://man7.org/linux/man-pages/man7/credentials.7.html
• Linux man-pages: capabilities(7): https://man7.org/linux/man-pages/man7/capabilities.7.html
• Linux man-pages: getent(1): https://man7.org/linux/man-pages/man1/getent.1.html
• Linux man-pages: nsswitch.conf(5): https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html
• GNU Coreutils qo'llanmasi: chown invocation: https://www.gnu.org/software/coreutils/manual/html_node/chown-invocation.html
• GNU Coreutils qo'llanmasi: chgrp invocation: https://www.gnu.org/software/coreutils/manual/html_node/chgrp-invocation.html
• POSIX.1-2024: file ownership: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html