SUSE-ի ապագա տեխնոլոգիաների զարգացման խմբի ղեկավար Թորստեն Կուկուկը (Future Technology Team, մշակում է openSUSE MicroOS և SLE Micro), ով նախկինում ղեկավարել է SUSE LINUX Enterprise Server նախագիծը 10 տարի շարունակ, առաջարկել է ազատվել /var/run/utmp ֆայլից։ բաշխումների մեջ՝ ամբողջությամբ լուծելու 2038 թվականի խնդիրը Glibc-ում: Բոլոր հավելվածները, որոնք օգտագործում են utmp, wtmp և lastlog, առաջարկվում է փոխակերպվել systemd-logind օգտագործող օգտատերերի ցուցակի ձեռքբերման:
19 թվականի հունվարի 2038-ին 32-բիթանոց time_t տիպով սահմանված ժամանակային ժամանակաչափերը կհեղեղեն: Glibc-ը, չնայած 64-բիթանոց time_t տիպի ներդրմանը, որոշ դեպքերում շարունակում է օգտագործել 32-բիթանոց time_t տիպը 64-բիթանոց հարթակներում՝ 32-բիթանոց օգտագործողի տարածության հավելվածների հետ համատեղելիությունը պահպանելու համար: Այդպիսի դեպքերից մեկը /var/run/utmp ֆայլն է, որը պահում է տվյալներ համակարգ մուտք գործող օգտվողների մասին: utmp-ում ժամանակի դաշտը նշված է 32-բիթանոց time_t արժեքի միջոցով:
Պարզապես utmp-ում ժամանակի դաշտը 32-բիթից 64-բիթանոց տիպի փոխարինելը չի աշխատի, քանի որ դա կհանգեցնի Glibc ABI-ի փոփոխության (տեսակը կփոխվի այնպիսի ֆունկցիաներում, ինչպիսիք են login(), getutid() և utmpname-ը: ()) և ընդհատում է համատեղելիությունը utmp օգտագործող հավելվածների հետ, ներառյալ w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ցուցադրման կառավարիչներ, emacs, openssh, qemu, samba, rsyslog և այլն: Հնարավոր թակարդների և բարդության առատության պատճառով utmp-ում time_t տիպը փոխարինելու գաղափարը մերժվեց Glibc մշակողների կողմից: Նույն պատճառով, utmp կառուցվածքում առկա ազատ տարածությունն օգտագործելու տարբերակը՝ լրացուցիչ 64-բիթանոց ժամանակային դաշտ ավելացնելու համար, մերժվեց:
Բացի այդ, utmp-ում տիպի բիթերի խորությունը փոխելը չի լուծում առկա այլ խնդիրներ, որոնցից ես նույնպես կցանկանայի ազատվել: Օրինակ, utmp-ում գրելը պահանջում է հատուկ իրավունքներ, ինչը պահանջում է գործընթացներին լրացուցիչ արտոնություններ տրամադրել: Մյուս խնդիրն այն է, որ utmp ճարտարապետությունը թույլ է տալիս տեղական օգտատերերին իրականացնել DoS հարձակումներ, ինչը հանգեցնում է utmp ծառայության խափանումների՝ ֆայլերի կողպեքների մանիպուլյացիայի միջոցով, ինչը անհնար է դարձնում վստահ լինել, որ utmp-ի բովանդակությունը արտացոլում է համակարգի իրական վիճակը: Առաջարկվում էր օգտագործել լրացուցիչ ֆոնային պրոցես՝ utmp-ի հասանելիությունը կարգավորելու համար, բայց նման առաջադրանքների համար արդեն կա systemd-logind գործընթաց, և մեկ այլ մասնագիտացված գործընթաց գործարկելը նպատակահարմար չէ (հավելվածները պետք է տվյալները փոխանցեն միաժամանակ երկու մշակողներին):
Միևնույն ժամանակ, նույնիսկ DoS հարձակումների հետ կապված խնդիրը լուծելիս, utmp-ի բովանդակությունը մնում է միայն տեղեկատվական և չի երաշխավորում իրականության արտացոլումը։ Օրինակ՝ տարբեր էմուլյատորներ և տերմինալային մուլտիպլեքսորներ տարբեր կերպ են արտացոլում իրենց վիճակը. հինգ GNOME տերմինալների գործարկումը կհանգեցնի նրան, որ մեկ օգտատեր կարտացոլվի utmp-ում, իսկ հինգ konsole կամ xterm տերմինալներ KDE-ում գործարկելու դեպքում՝ վեց: Screen-ի և tmux-ի վարքագիծը նմանապես տարբեր է. առաջին դեպքում յուրաքանչյուր նիստ հաշվվում է որպես առանձին օգտատեր, իսկ երկրորդում՝ միայն մեկ օգտատեր է արտացոլվում բոլոր նիստերի համար:
Արդյունքում, որպես ամենապարզ լուծում, առաջարկվում է բոլոր հավելվածները փոխանցել արդեն գոյություն ունեցող այլընտրանքային systemd-logind ծառայությունից և, երբ ընթացիկ ծրագրերը չեն մուտք գործում utmp, դադարեցնել ձայնագրումը utmp: Wtmp-ին փոխարինելու համար առաջարկվում է պատրաստել ծրագրային ինտերֆեյսներ՝ systemd-journald օգտագործող օգտատերերի մասին տեղեկատվություն գրելու և կարդալու համար: Systemd 254-ի հաջորդ թողարկման կոդերի բազան արդեն ներառում է անհրաժեշտ ֆունկցիոնալությունը՝ utmp-ի փոխարինման տվյալները libsystemd-ի միջոցով՝ օգտագործելով sd-login.h API կամ DBUS-ի միջոցով:
Source: opennet.ru