SUSE (ఫ్యూచర్ టెక్నాలజీ టీమ్, openSUSE మైక్రోఓఎస్ మరియు SLE మైక్రోలను అభివృద్ధి చేస్తుంది)లో ఫ్యూచర్ టెక్నాలజీ డెవలప్‌మెంట్ గ్రూప్ నాయకుడు థోర్‌స్టెన్ కుకుక్, గతంలో 10 సంవత్సరాల పాటు SUSE LINUX ఎంటర్‌ప్రైజ్ సర్వర్ ప్రాజెక్ట్‌కు నాయకత్వం వహించి, /var/run/utmp ఫైల్‌ను వదిలించుకోవాలని సూచించారు. Glibcలో 2038 సమస్యను పూర్తిగా పరిష్కరించడానికి పంపిణీలలో. utmp, wtmp మరియు లాస్ట్‌లాగ్‌ని ఉపయోగించే అన్ని అప్లికేషన్‌లు systemd-logind ఉపయోగించి వినియోగదారుల జాబితాను పొందేందుకు మార్చబడాలని ప్రతిపాదించబడ్డాయి.
జనవరి 19, 2038న, 32-బిట్ time_t రకం ద్వారా పేర్కొన్న ఎపోచల్ టైమ్ కౌంటర్‌లు ఓవర్‌ఫ్లో అవుతాయి. Glibc, 64-బిట్ టైమ్_టి రకాన్ని పరిచయం చేసినప్పటికీ, 32-బిట్ యూజర్ స్పేస్ అప్లికేషన్‌లతో అనుకూలతను కొనసాగించడానికి 64-బిట్ ప్లాట్‌ఫారమ్‌లలో కొన్ని సందర్భాల్లో 32-బిట్ టైమ్_టి రకాన్ని ఉపయోగించడం కొనసాగిస్తుంది. అటువంటి సందర్భంలో ఒకటి /var/run/utmp ఫైల్, ఇది ప్రస్తుతం సిస్టమ్‌లోకి లాగిన్ అయిన వినియోగదారుల గురించి డేటాను నిల్వ చేస్తుంది. utmpలో సమయ క్షేత్రం 32-బిట్ time_t విలువను ఉపయోగించి పేర్కొనబడింది.
utmpలో టైమ్ ఫీల్డ్‌ను 32-బిట్ నుండి 64-బిట్ రకానికి మార్చడం పని చేయదు, ఎందుకంటే ఇది Glibc ABIలో మార్పుకు దారి తీస్తుంది (లాగిన్(), getutid() మరియు utmpname వంటి ఫంక్షన్‌లలో రకం మారుతుంది ()) మరియు w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog మొదలైన వాటితో సహా utmpని ఉపయోగించే అప్లికేషన్‌లతో బ్రేకింగ్ అనుకూలత. సంభావ్య ఆపదలు మరియు సంక్లిష్టత యొక్క సమృద్ధి కారణంగా, utmpలో time_t రకాన్ని భర్తీ చేయాలనే ఆలోచన Glibc డెవలపర్‌లచే తిరస్కరించబడింది. అదే కారణంగా, అదనపు 64-బిట్ టైమ్ ఫీల్డ్‌ని జోడించడానికి utmp నిర్మాణంలో అందుబాటులో ఉన్న ఖాళీ స్థలాన్ని ఉపయోగించే ఎంపిక విస్మరించబడింది.
అదనంగా, utmpలో టైప్ బిట్ డెప్త్‌ని మార్చడం వలన ఇప్పటికే ఉన్న ఇతర సమస్యలను పరిష్కరించదు, నేను కూడా వదిలించుకోవాలనుకుంటున్నాను. ఉదాహరణకు, utmpకి వ్రాయడానికి ప్రత్యేక హక్కులు అవసరం, దీనికి ప్రక్రియలు అదనపు అధికారాలను మంజూరు చేయడం అవసరం. మరొక సమస్య ఏమిటంటే, utmp నిర్మాణం స్థానిక వినియోగదారులను DoS దాడులను నిర్వహించడానికి అనుమతిస్తుంది, ఇది ఫైల్ లాక్‌లను తారుమారు చేయడం ద్వారా utmp సేవకు అంతరాయం కలిగిస్తుంది, ఇది utmp యొక్క కంటెంట్‌లు సిస్టమ్‌లోని వాస్తవ స్థితిని ప్రతిబింబిస్తున్నాయని నిర్ధారించుకోవడం అసాధ్యం. utmpకి యాక్సెస్‌ని నిర్వహించడానికి అదనపు బ్యాక్‌గ్రౌండ్ ప్రాసెస్‌ని ఉపయోగించాలని ప్రతిపాదించబడింది, కానీ అలాంటి పనులకు ఇప్పటికే systemd-logind ప్రక్రియ ఉంది మరియు మరొక ప్రత్యేక ప్రక్రియను ప్రారంభించడం మంచిది కాదు (అప్లికేషన్‌లు ఏకకాలంలో ఇద్దరు హ్యాండ్లర్‌లకు డేటాను బదిలీ చేయాలి).
అదే సమయంలో, DoS దాడులతో సమస్యను పరిష్కరిస్తున్నప్పుడు కూడా, utmp యొక్క కంటెంట్‌లు సమాచారంగా మాత్రమే ఉంటాయి మరియు వాస్తవికత యొక్క ప్రతిబింబానికి హామీ ఇవ్వవు. ఉదాహరణకు, వివిధ ఎమ్యులేటర్‌లు మరియు టెర్మినల్ మల్టీప్లెక్సర్‌లు వాటి స్థితిని విభిన్నంగా ప్రతిబింబిస్తాయి - ఐదు గ్నోమ్ టెర్మినల్స్‌ను ప్రారంభించడం వలన ఒక వినియోగదారు utmpలో ప్రతిబింబిస్తారు మరియు KDEలో ఐదు కాన్సోల్ లేదా xterm టెర్మినల్స్ ప్రారంభించడం వలన ఆరు ఫలితాలు వస్తాయి. స్క్రీన్ మరియు tmux ప్రవర్తన కూడా అదే విధంగా భిన్నంగా ఉంటుంది: మొదటి సందర్భంలో, ప్రతి సెషన్ ప్రత్యేక వినియోగదారుగా పరిగణించబడుతుంది మరియు రెండవది, అన్ని సెషన్‌లకు ఒక వినియోగదారు మాత్రమే ప్రతిబింబిస్తారు.
ఫలితంగా, సరళమైన పరిష్కారంగా, ఇప్పటికే ఉన్న ప్రత్యామ్నాయ systemd-logind సేవను ఉపయోగించడానికి అన్ని అప్లికేషన్‌లను బదిలీ చేయాలని ప్రతిపాదించబడింది మరియు utmpని యాక్సెస్ చేసే ప్రస్తుత ప్రోగ్రామ్‌లు లేన తర్వాత, utmpకి రికార్డింగ్‌ని ఆపండి. wtmpని భర్తీ చేయడానికి, systemd-journaldని ఉపయోగించే వినియోగదారుల గురించి సమాచారాన్ని వ్రాయడం మరియు చదవడం కోసం సాఫ్ట్‌వేర్ ఇంటర్‌ఫేస్‌లను సిద్ధం చేయాలని ప్రతిపాదించబడింది. systemd 254 యొక్క తదుపరి విడుదల కోసం కోడ్‌బేస్ ఇప్పటికే sd-login.h APIని ఉపయోగించి లేదా DBUS ద్వారా libsystemd ద్వారా utmp రీప్లేస్‌మెంట్ డేటాను అందించడానికి అవసరమైన కార్యాచరణను కలిగి ఉంది.
మూలం: opennet.ru