PrivateTmp: hook-ը գրեց ֆայլը, իսկ ո՞ւր գնաց այն։

Hook-երը հայտնում են հաջողության մասին, և նույն ուղին դեռ դատարկ է թվում shell-ից։ Երկու պնդումներն էլ կարող են միաժամանակ ճիշտ լինել, քանի որ systemd ծառայությունը կարող է ապրել իր mount անվանատարածքում՝ մասնավոր ժամանակավոր պանակով։ Երբ դա հասկացվի, հետաքրքիր հարցը դառնում է՝ արդյոք գրառումն ընդհանրապես հաջողվել է։

Երկու ժամանակավոր պանակ, մեկ ուղի

Մեկուսացման կարգավորումը միավորին տալիս է ժամանակավոր պանակների մասնավոր տեսք՝ դրանք միայն կարդալու դարձնելու փոխարեն։ Միավորից դուրս գործընթացները չեն տեսնում, թե այն ինչ է գրում այնտեղ, և այն ամենը, ինչ նա թողնում է հետևում, դեն է նետվում, երբ միավորը կանգ է առնում։ Ուստի hook-ի տպած ուղին և shell-ից ստուգված ուղին կարող են վերաբերել նույն անունով տարբեր օբյեկտների։

Սա տեսանելիության խնդիր է, և այն նման է տվյալների կորստի խնդրի։ Ոչինչ չի ջնջվել, որովհետև ֆայլը պարզապես գտնվում է անվանատարածքում, որի անդամ shell-ը չէ։ Նույն հրամանը տարբեր է վարվում միավորի ներսում գործարկվելիս, և հենց այդ դիտարկումն է սովորաբար լուծում վեճը։ Կարդացեք միավորի կարգավորումները նախքան գրառման մասին որևէ եզրակացություն անելը։

Առանձնացրեք անտեսանելին անգրելիից

Հաջող գրառումը և ձախողված բացումը տարբեր ապացույցներ են տալիս, և այդ տարբերությունը որոշում է վերանորոգումը։ Եթե hook-ը ասում է, որ ֆայլը ստեղծվել է, բայց արտաքին ընթերցողը չի գտնում այն, ապա դուք անվանատարածքի հարց ունեք։ Եթե hook-ը հաղորդում է թույլտվության սխալ կամ ձախողված բացում, ապա ֆայլը երբեք չի գրվել, և անվանատարածքի ոչ մի փոփոխություն չի օգնի։

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

Գործընթացի արմատի ուղին ցույց է տալիս ծառայության սեփական ֆայլային համակարգի տեսքը՝ կախված այդ գործընթացի թույլտվությունների ստուգումից, քանի դեռ այն աշխատում է։ Կարդացեք միավորի մատյանը նույն նստաշրջանում, որովհետև գրառման սխալն ու բացակայող ֆայլը հեշտ է շփոթել, երբ ինչ-որ մեկն արդեն որոշել է պատճառը։

Ընդհանուր տվյալներին տվեք հստակ տեղ

Տվյալները, որոնք միայն ծառայությանն են պետք, տեղ ունեն նրա մասնավոր ժամանակավոր պանակում։ Տվյալները, որոնք պետք է կարդա մեկ այլ գործընթաց, պահանջում են երկուսի համար սահմանված ուղի՝ նշված սեփականատիրոջ, ռեժիմի և ժամկետի հետ։ Որոշեք, թե երկուսից որն ունեք, նախքան միավորը խմբագրելը։ Այս դեպքերի մեծ մասը գալիս է նրանից, որ մասնավոր ֆայլը վերաբերվում է որպես ընդհանուր։

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

Գործարկման պանակը տեղադրում է թղթապանակը համակարգի գործարկման տարածքի տակ, ստեղծում է այն միավորի կարգավորված օգտատիրոջ և խմբի համար և հեռացնում է այն, երբ միավորը կանգ է առնում։ Ավելացրեք այն drop-in-ի միջոցով, որպեսզի փաթեթի միավորը մնա անձեռնմխելի, ապա վերաբեռնեք կառավարիչը և վերսկսեք այդ օրինակը՝ ընդունելով, որ դրա հաճախորդները նորից կմիանան։

Պահեք ցանկացած գործարկման պանակ, որն արդեն պահանջում է տեղադրված միավորը։ Ցանկը փոխարինելը՝ դրան ավելացնելու փոխարեն, սովորական միջոց է կոտրելու անկապ գործառույթ, որը ոչ ոք չի կապում փոփոխության հետ։

Արտոնությունների երկու շերտ կարող են չհամաձայնել

Ծառայությունների կառավարիչը պանակը ստեղծում է միավորի կարգավորված օգտատիրոջ համար, մինչդեռ VPN դեմոնը կարող է առանձին իջնել իր սեփական հաշվին նախքան միացման hook-ը գործարկելը։ Դրանք տարբեր շերտեր են, և նրանք կարող են տարբեր ինքնություններ նշել։

Root-ին պատկանող սահմանափակող ռեժիմով պանակը լիովին տեսանելի է դեմոնի համար, որն արդեն հրաժարվել է արտոնություններից, և այնուամենայնիվ անգրելի է նրա համար։ Այդ ժամանակ սխալը կարդացվում է որպես թույլտվության խնդիր, չնայած ուղին գոյություն ունի հենց այնտեղ, որտեղ սպասում էիք։ Համեմատեք պանակի սեփականատիրոջը hook-ի հաղորդած ինքնության հետ։ Երբ դրանք տարբերվում են, ռեժիմը երբեք հարց չի եղել։

Ստուգեք, թե hook-ը իրականում որ ինքնության ներքո է աշխատում, նախքան սեփականատիրությունը փոխելը։ Ծառայության կատարման օգտատերին փոխելը՝ պանակը շտկելու համար, կարող է փոխել սարքերի հասանելիությունը և ցանցային արտոնություններն այլ տեղերում, ինչը մեծ գին է փոքր խնդրի համար։

Ստուգեք ամբողջ հանձնումը

Միանգամից հաստատեք չորս բան՝ hook-ը գրում է իր իրական ինքնության ներքո, նախատեսված ընթերցողը կարող է օգտագործել ֆայլը, անկապ օգտատերերը չեն կարող, և միավորի կանգը մաքրում է այնպես, ինչպես նախագծված է։ Ֆայլի հայտնվելը հոսթի ընդհանուր ժամանակավոր պանակում պահանջ չէ, և դա սովորաբար նշան է, որ փոխանակումը երբեք չի ստացել իր սեփական ուղին։ Փորձարկեք ընթերցողին վերսկսումից հետո, ոչ միայն առաջին գործարկման ժամանակ։ Մաքրման վարքը նախագծի մաս է, ուստի դիտարկեք այն, փոխարենը ենթադրելու։

Մշտական վիճակը տեղ ունի այնտեղ, որտեղ կյանքի տևողությունը համապատասխանում է, քանի որ գործարկման պանակը նախատեսված է անհետանալու։ Ընտրեք տեղը ըստ կյանքի տևողության, ոչ ըստ հարմարության։ Այդ սովորությունը կանխում է նույն հետաքննության հաջորդ տարբերակը։