Årets problem 2038 kan göra att en del av programvaran misslyckas det året. Problemet påverkar program som använder den POSIX-baserade representationen av tid.
Thorsten Kukuk, lagledare från SUSE Future Technology (Future Technology Team, utvecklar openSUSE MicroOS och SLE Micr ), som tidigare lett SUSE LINUX Enterprise Server-projektet i 10 år, föreslog att du skulle bli av med filen /var/run/utmp i utdelningar för att helt ta itu med Y2038-problemet i Glibc.
Med det Det föreslås att alla applikationer som använder utmp, wtmp och lastlog flyttas för att få en lista över användare som använder systemd-login.
Den 19 januari 2038 kommer timers att svämma över av angiven period av typen 32-bitars time_t. I Glibc, trots introduktionen av 64-bitars time_t-typen, för att upprätthålla kompatibilitet med 32-bitars användarutrymmesapplikationer, används fortfarande 32-bitars time_t-typen i vissa fall på 64-bitars plattformar.
Det finns två huvudproblem med utmp/utmpx med glibc på t.ex. x86-64:
Ett 32-bitars time_t-fält används för tiden, som kommer att svämma över vid 2038
Det finns designproblem som tillåter en DoS-attack (utmp/wtmp-blockering tillåter en oprivilegierad användare att neka tjänst)
En analys av det andra problemet av glibc-utvecklarna visade att ytterligare en demon skulle krävas för att hantera utmp/utmpx-åtkomst.Även om det finns några fler problem...
Ett sådant fall är filen /var/run/utmp, som lagrar data om de användare som för närvarande är anslutna till systemet. Tidsfältet i utmp ställs in med ett 32-bitars time_t-värde.
Det nämns att, att helt enkelt ändra ett fält i utmp över tiden från en 32-bitarstyp till en 64-bitarstyp fungerar inte, eftersom detta kommer att ändra Glibc ABI (typen kommer att ändras i funktioner som login(), getutid() och utmpname()) och bryter kompatibiliteten med applikationer som använder utmp, inklusive w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc.
På grund av överflöd av potentiella fallgropar och flit, utvecklarna av Glibc avvisade idén om att ersätta bitlängden för time_t-typen i utmp. Av samma anledning har alternativet att använda det tillgängliga utrymmet i utmp-strukturen för att lägga till ytterligare 64-bitars tidsfält tagits bort.
Att ändra bitdjupet för typen i utmp löser inte heller andra befintliga problem, till exempel att skriva till utmp kräver speciella behörigheter, vilket kräver att processer ges ytterligare privilegier. Ett annat problem är att utmp-arkitekturen tillåter lokala användare att utföra DoS-attacker som bryter utmp-tjänsten genom att manipulera fillås, vilket gör det omöjligt att vara säker på att innehållet i utmp återspeglar systemets faktiska tillstånd.
Det föreslogs att använda en ytterligare bakgrundsprocess för att hantera åtkomst till utmp, men för sådana uppgifter finns det redan en systemd-login process och det rekommenderas inte att starta en annan specialiserad process (applikationer måste överföra data till två kontroller samtidigt).
Samtidigt, även genom att lösa problemet med DoS-attacker, förblir innehållet i utmp endast informativt, utan att garantera en återspegling av verkligheten.
Till exempel reflekterar olika terminalemulatorer och multiplexorer sitt tillstånd på olika sätt: att köra fem GNOME-terminaler kommer att resultera i att en användare speglas i utmp, medan att köra fem konsole- eller xterm-terminaler i KDE kommer att resultera i sex. På samma sätt skiljer sig beteendet hos screen och tmux, i det första fallet räknas varje session som en separat användare och i det andra reflekteras endast en användare för alla sessioner.
Som ett resultat, som den enklaste lösningen, Det föreslås att alla applikationer portas för att använda tjänsten systemd-login alternativ som redan finns och, efter att inga riktiga program kommer åt utmp, sluta skriva till utmp. För att ersätta wtmp föreslås det att förbereda API:er för att skriva och läsa information om användare som använder systemd-journald.
Slutligen är det värt att nämna att kodbasen för nästa version av systemd 254 innehåller redan de nödvändiga funktionerna att tillhandahålla ersättningsutmp-data via libsystemd med sd-login.ho API via DBUS.
Om du är intresserad av att veta mer om det kan du konsultera detaljerna I följande länk.