Да би се Глибц решио проблема 2038, предлаже се престанак коришћења утмп-а

Тхорстен Кукук, вођа групе за будући развој технологије у СУСЕ-у (Футуре Тецхнологи Теам, развија опенСУСЕ МицроОС и СЛЕ Мицро), који је претходно водио пројекат СУСЕ ЛИНУКС Ентерприсе Сервер 10 година, предложио је да се отарасите /вар/рун/утмп датотеке у дистрибуцијама како би се у потпуности решио проблем из 2038. у Глибцу. Предлаже се да се све апликације које користе утмп, втмп и ластлог конвертују у добијање листе корисника користећи системд-логинд.

19. јануара 2038. епохални бројачи времена специфицирани 32-битним типом тиме_т ће се прелити. Глибц, упркос увођењу 64-битног типа тиме_т, наставља да користи 32-битни тип тиме_т у неким случајевима на 64-битним платформама како би одржао компатибилност са 32-битним апликацијама корисничког простора. Један такав случај је датотека /вар/рун/утмп, која чува податке о корисницима који су тренутно пријављени на систем. Временско поље у утмп-у је наведено коришћењем 32-битне вредности тиме_т.

Једноставна замена временског поља у утмп-у са 32-битног на 64-битни тип неће радити, јер ће то довести до промене у Глибц АБИ-у (тип ће се променити у функцијама као што су логин(), гетутид() и утмпнаме ()) и нарушавање компатибилности са апликацијама које користе утмп, укључујући в, вхо, уптиме, логин, су, судо, усерадд, системд, сисвинит, тцсх, ктерм менаџере приказа, емацс, опенссх, кему, самба, рсислог, итд. Због обиља могућих замки и сложености, Глибц програмери су одбацили идеју о замени типа тиме_т у утмп-у. Из истог разлога, опција коришћења доступног слободног простора у утмп структури за додавање додатног 64-битног временског поља је одбачена.

Поред тога, промена дубине бита типа у утмп-у не решава друге постојеће проблеме којих бих такође желео да се решим. На пример, писање у утмп захтева посебне дозволе, што захтева да процеси добију додатне привилегије. Други проблем је што утмп архитектура дозвољава локалним корисницима да изводе ДоС нападе, што доводи до прекида утмп услуге кроз манипулацију закључавања датотека, што онемогућава да будемо сигурни да садржај утмп-а одражава стварно стање у систему. Предложено је да се користи додатни позадински процес за руковање приступом утмп-у, али за такве задатке већ постоји системд-логинд процес и није препоручљиво покретање другог специјализованог процеса (апликације ће морати да пренесу податке на два руковаоца истовремено).

Истовремено, чак и при решавању проблема са ДоС нападима, садржај утмп остаје само информативни и не гарантује одраз стварности. На пример, различити емулатори и терминалски мултиплексери различито одражавају своје стање - покретање пет ГНОМЕ терминала ће резултирати да један корисник буде приказан у утмп-у, а покретање пет консоле или ктерм терминала у КДЕ-у ће резултирати са шест. Понашање екрана и тмук-а се слично разликује: у првом случају, свака сесија се рачуна као посебан корисник, ау другом, само један корисник се одражава за све сесије.

Као резултат тога, као најједноставније решење, предлаже се пребацивање свих апликација на коришћење већ постојеће алтернативне системд-логинд сервиса и, након што нема тренутних програма који приступају утмп-у, престати са снимањем на утмп. За замену втмп-а, предлаже се припрема софтверских интерфејса за писање и читање информација о корисницима помоћу системд-јоурналд. База кода за следеће издање системд 254 већ укључује неопходну функционалност за обезбеђивање података утмп замене преко либсистемд користећи сд-логин.х АПИ или преко ДБУС-а.

Извор: опеннет.ру

Додај коментар