Y2038 સમસ્યામાંથી Glibc ને છુટકારો મેળવવા માટે utmp નો ઉપયોગ બંધ કરવાનો પ્રસ્તાવ

SUSE ખાતે ફ્યુચર ટેક્નોલોજી ટીમના લીડર થોર્સ્ટન કુકુક (ફ્યુચર ટેક્નોલોજી ટીમ, openSUSE MicroOS અને SLE Micro વિકસાવે છે), જેમણે અગાઉ 10 વર્ષ સુધી SUSE LINUX Enterprise સર્વર પ્રોજેક્ટનું નેતૃત્વ કર્યું હતું, તેમણે /var/run/utmp ફાઇલમાંથી છૂટકારો મેળવવાનું સૂચન કર્યું. Glibc માં Y2038 સમસ્યાને સંપૂર્ણ રીતે ઉકેલવા માટે વિતરણો. utmp, wtmp અને લાસ્ટલોગનો ઉપયોગ કરતી તમામ એપ્લિકેશનોને systemd-logind નો ઉપયોગ કરીને વપરાશકર્તાઓની સૂચિ મેળવવા માટે ખસેડવાની દરખાસ્ત છે.

19 જાન્યુઆરી, 2038 ના રોજ, 32-બીટ ટાઇમ_ટી પ્રકાર દ્વારા ઉલ્લેખિત યુગ સમય કાઉન્ટર્સ ઓવરફ્લો થશે. Glibc માં, 64-બીટ ટાઇમ_ટી પ્રકારની રજૂઆત છતાં, 32-બીટ યુઝર-સ્પેસ એપ્લીકેશનો સાથે સુસંગતતા જાળવવા માટે, 64-બીટ ટાઇમ_ટી પ્રકાર હજુ પણ કેટલાક કિસ્સાઓમાં 32-બીટ પ્લેટફોર્મ પર વપરાય છે. આવો જ એક કેસ /var/run/utmp ફાઇલ છે, જે હાલમાં સિસ્ટમમાં લૉગ ઇન થયેલા વપરાશકર્તાઓ વિશેનો ડેટા સંગ્રહિત કરે છે. utmp માં ટાઇમ ફીલ્ડ 32-bit time_t મૂલ્યનો ઉપયોગ કરીને સેટ કરેલ છે.

ફક્ત 32-બીટથી 64-બીટ પ્રકારમાં સમય જતાં utmp માં ફીલ્ડ બદલવાનું કામ કરશે નહીં, કારણ કે આ Glibc ABI (લોગિન(), getutid() અને utmpname() જેવા કાર્યોમાં બદલાશે. અને w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ડિસ્પ્લે મેનેજર્સ, emacs, openssh, qemu, સામ્બા, rsyslog, વગેરે સહિત utmp નો ઉપયોગ કરતી એપ્લિકેશનો સાથે સુસંગતતા તોડી નાખો. સંભવિત મુશ્કેલીઓ અને પરિશ્રમની વિપુલતાને લીધે, utmp માં time_t પ્રકારની બીટ લંબાઈ બદલવાનો વિચાર Glibc ના વિકાસકર્તાઓ દ્વારા નકારી કાઢવામાં આવ્યો હતો. આ જ કારણોસર, વધારાના 64-બીટ સમય ફીલ્ડ ઉમેરવા માટે utmp માળખામાં ઉપલબ્ધ જગ્યાનો ઉપયોગ કરવાનો વિકલ્પ છોડી દેવામાં આવ્યો હતો.

વધુમાં, utmp માં પ્રકારની બીટ ઊંડાઈ બદલવાથી અન્ય હાલની સમસ્યાઓ હલ થતી નથી, જેમાંથી હું પણ છુટકારો મેળવવા માંગુ છું. ઉદાહરણ તરીકે, utmp પર લખવા માટે વિશેષ પરવાનગીઓની જરૂર પડે છે, જેના માટે પ્રક્રિયાઓને વધારાના વિશેષાધિકારોની જરૂર પડે છે. બીજી સમસ્યા એ છે કે utmp આર્કિટેક્ચર સ્થાનિક વપરાશકર્તાઓને DoS હુમલાઓ કરવા દે છે જે ફાઇલ લૉક્સની હેરફેર દ્વારા utmp સેવાને તોડે છે, તે ખાતરી કરવી અશક્ય બનાવે છે કે utmp ની સામગ્રી સિસ્ટમમાં વાસ્તવિક સ્થિતિને પ્રતિબિંબિત કરે છે. યુટીએમપીની ઍક્સેસને હેન્ડલ કરવા માટે વધારાની પૃષ્ઠભૂમિ પ્રક્રિયાનો ઉપયોગ કરવાની દરખાસ્ત કરવામાં આવી હતી, પરંતુ આવા કાર્યો માટે પહેલેથી જ એક સિસ્ટમડ-લોગિન પ્રક્રિયા છે અને બીજી વિશિષ્ટ પ્રક્રિયા શરૂ કરવાની સલાહ આપવામાં આવતી નથી (એપ્લિકેશને એક જ સમયે બે હેન્ડલર્સને ડેટા ટ્રાન્સફર કરવો પડશે) .

તે જ સમયે, DoS હુમલાઓ સાથે સમસ્યા હલ કરતી વખતે પણ, utmp ની સામગ્રી માત્ર માહિતીપ્રદ રહે છે, વાસ્તવિકતાના પ્રતિબિંબની બાંયધરી આપતી નથી. ઉદાહરણ તરીકે, વિવિધ ટર્મિનલ ઇમ્યુલેટર અને મલ્ટિપ્લેક્સર્સ તેમની સ્થિતિને અલગ રીતે પ્રતિબિંબિત કરે છે - પાંચ જીનોમ ટર્મિનલ ચલાવવાથી એક વપરાશકર્તા utmp માં પ્રતિબિંબિત થશે, જ્યારે KDE માં પાંચ કોન્સોલ અથવા xterm ટર્મિનલ ચલાવવાથી છ પરિણામ આવશે. એ જ રીતે, સ્ક્રીન અને tmux ની વર્તણૂક અલગ છે, પ્રથમ કિસ્સામાં દરેક સત્રને એક અલગ વપરાશકર્તા તરીકે ગણવામાં આવે છે, અને બીજામાં બધા સત્રો માટે માત્ર એક વપરાશકર્તા પ્રતિબિંબિત થાય છે.

પરિણામે, સૌથી સરળ ઉકેલ તરીકે, પહેલેથી અસ્તિત્વમાં છે તે વૈકલ્પિક systemd-logind સેવાનો ઉપયોગ કરવા માટે તમામ એપ્લિકેશનોને સ્થાનાંતરિત કરવાની દરખાસ્ત કરવામાં આવી છે અને, utmp ને ઍક્સેસ કરતા કોઈ વાસ્તવિક પ્રોગ્રામ્સ ન હોય તો, utmp પર લખવાનું બંધ કરો. wtmp ને બદલવા માટે, systemd-journald નો ઉપયોગ કરતા વપરાશકર્તાઓ વિશે માહિતી લખવા અને વાંચવા માટે API તૈયાર કરવાનો પ્રસ્તાવ છે. systemd 254 ના આગામી પ્રકાશન માટેના કોડબેઝમાં sd-login.h API નો ઉપયોગ કરીને અથવા DBUS મારફતે libsystemd મારફતે રિપ્લેસમેન્ટ utmp ડેટા પ્રદાન કરવા માટે જરૂરી કાર્યો પહેલેથી જ સમાવે છે.

સોર્સ: opennet.ru