ಈ ಹಿಂದೆ 10 ವರ್ಷಗಳ ಕಾಲ SUSE LINUX ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವರ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಮುನ್ನಡೆಸಿದ್ದ SUSE (ಫ್ಯೂಚರ್ ಟೆಕ್ನಾಲಜಿ ಟೀಮ್, openSUSE MicroOS ಮತ್ತು SLE Micro ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ) ನಲ್ಲಿ ಭವಿಷ್ಯದ ತಂತ್ರಜ್ಞಾನ ತಂಡದ ನಾಯಕರಾದ Thorsten Kukuk, ರಲ್ಲಿ /var/run/utmp ಫೈಲ್ ಅನ್ನು ತೊಡೆದುಹಾಕಲು ಸಲಹೆ ನೀಡಿದರು. Glibc ನಲ್ಲಿ Y2038 ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲು ವಿತರಣೆಗಳು. utmp, wtmp ಮತ್ತು ಲಾಸ್ಟ್‌ಲಾಗ್ ಅನ್ನು ಬಳಸುವ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು systemd-logind ಬಳಸುವ ಬಳಕೆದಾರರ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಲು ಸರಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ.
ಜನವರಿ 19, 2038 ರಂದು, 32-ಬಿಟ್ time_t ಪ್ರಕಾರದಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಯುಗ ಸಮಯದ ಕೌಂಟರ್‌ಗಳು ಓವರ್‌ಫ್ಲೋ ಆಗುತ್ತವೆ. Glibc ನಲ್ಲಿ, 64-bit time_t ಪ್ರಕಾರದ ಪರಿಚಯದ ಹೊರತಾಗಿಯೂ, 32-ಬಿಟ್ ಬಳಕೆದಾರ-ಸ್ಥಳ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು, 64-bit time_t ಪ್ರಕಾರವನ್ನು ಇನ್ನೂ ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ 32-ಬಿಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಅಂತಹ ಒಂದು ಪ್ರಕರಣವೆಂದರೆ /var/run/utmp ಫೈಲ್, ಇದು ಪ್ರಸ್ತುತ ಸಿಸ್ಟಮ್‌ಗೆ ಲಾಗ್ ಇನ್ ಆಗಿರುವ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. utmp ನಲ್ಲಿ ಸಮಯ ಕ್ಷೇತ್ರವನ್ನು 32-ಬಿಟ್ time_t ಮೌಲ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಂದಿಸಲಾಗಿದೆ.
32-ಬಿಟ್‌ನಿಂದ 64-ಬಿಟ್ ಪ್ರಕಾರಕ್ಕೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಯುಟಿಎಂಪಿಯಲ್ಲಿ ಕ್ಷೇತ್ರವನ್ನು ಬದಲಾಯಿಸುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಗ್ಲಿಬ್‌ಸಿ ಎಬಿಐ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ (ಲಾಗಿನ್(), getutid() ಮತ್ತು utmpname() ನಂತಹ ಕಾರ್ಯಗಳಲ್ಲಿ ಪ್ರಕಾರವು ಬದಲಾಗುತ್ತದೆ. ಮತ್ತು w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ಡಿಸ್ಪ್ಲೇ ಮ್ಯಾನೇಜರ್‌ಗಳು, emacs, openssh, qemu, samba, rsyslog, ಇತ್ಯಾದಿ ಸೇರಿದಂತೆ utmp ಅನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಮುರಿಯಿರಿ. ಸಂಭವನೀಯ ಅಪಾಯಗಳು ಮತ್ತು ಪ್ರಯಾಸದಾಯಕತೆಯ ಹೇರಳತೆಯ ಕಾರಣದಿಂದಾಗಿ, utmp ನಲ್ಲಿ time_t ಪ್ರಕಾರದ ಬಿಟ್ ಉದ್ದವನ್ನು ಬದಲಿಸುವ ಕಲ್ಪನೆಯನ್ನು Glibc ನ ಅಭಿವರ್ಧಕರು ತಿರಸ್ಕರಿಸಿದರು. ಅದೇ ಕಾರಣಕ್ಕಾಗಿ, ಹೆಚ್ಚುವರಿ 64-ಬಿಟ್ ಸಮಯ ಕ್ಷೇತ್ರವನ್ನು ಸೇರಿಸಲು utmp ರಚನೆಯಲ್ಲಿ ಲಭ್ಯವಿರುವ ಸ್ಥಳವನ್ನು ಬಳಸುವ ಆಯ್ಕೆಯನ್ನು ಕೈಬಿಡಲಾಗಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, utmp ನಲ್ಲಿನ ಬಿಟ್ ಆಳವನ್ನು ಬದಲಾಯಿಸುವುದರಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ನಾನು ತೊಡೆದುಹಾಕಲು ಬಯಸುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, utmp ಗೆ ಬರೆಯಲು ವಿಶೇಷ ಅನುಮತಿಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ, ಇದಕ್ಕೆ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಹೆಚ್ಚುವರಿ ಸವಲತ್ತುಗಳನ್ನು ನೀಡಬೇಕಾಗುತ್ತದೆ. ಇನ್ನೊಂದು ಸಮಸ್ಯೆಯೆಂದರೆ utmp ಆರ್ಕಿಟೆಕ್ಚರ್ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರಿಗೆ DoS ದಾಳಿಗಳನ್ನು ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಅದು ಫೈಲ್ ಲಾಕ್‌ಗಳ ಕುಶಲತೆಯ ಮೂಲಕ utmp ಸೇವೆಯನ್ನು ಮುರಿಯುತ್ತದೆ, utmp ಯ ವಿಷಯಗಳು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ನೈಜ ಸ್ಥಿತಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ. utmp ಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚುವರಿ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಳಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ಅಂತಹ ಕಾರ್ಯಗಳಿಗೆ ಈಗಾಗಲೇ systemd-ಲಾಗಿಂಡ್ ಪ್ರಕ್ರಿಯೆ ಇದೆ ಮತ್ತು ಮತ್ತೊಂದು ವಿಶೇಷ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಸೂಕ್ತವಲ್ಲ (ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ಹ್ಯಾಂಡ್ಲರ್‌ಗಳಿಗೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಬೇಕಾಗುತ್ತದೆ) .
ಅದೇ ಸಮಯದಲ್ಲಿ, DoS ದಾಳಿಯೊಂದಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಾಗಲೂ, utmp ಯ ವಿಷಯವು ಕೇವಲ ಮಾಹಿತಿಯಾಗಿರುತ್ತದೆ, ವಾಸ್ತವದ ಪ್ರತಿಬಿಂಬವನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ವಿಭಿನ್ನ ಟರ್ಮಿನಲ್ ಎಮ್ಯುಲೇಟರ್‌ಗಳು ಮತ್ತು ಮಲ್ಟಿಪ್ಲೆಕ್ಸರ್‌ಗಳು ತಮ್ಮ ಸ್ಥಿತಿಯನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ - ಐದು GNOME ಟರ್ಮಿನಲ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದರಿಂದ ಒಬ್ಬ ಬಳಕೆದಾರನು utmp ನಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ, ಆದರೆ KDE ಯಲ್ಲಿ ಐದು ಕನ್ಸೋಲ್ ಅಥವಾ xterm ಟರ್ಮಿನಲ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಆರು ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ. ಅಂತೆಯೇ, ಪರದೆಯ ಮತ್ತು tmux ನ ನಡವಳಿಕೆಯು ಭಿನ್ನವಾಗಿರುತ್ತದೆ, ಮೊದಲ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರತಿ ಸೆಶನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರರಂತೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದರಲ್ಲಿ ಎಲ್ಲಾ ಸೆಷನ್‌ಗಳಿಗೆ ಒಬ್ಬ ಬಳಕೆದಾರನು ಮಾತ್ರ ಪ್ರತಿಫಲಿಸುತ್ತಾನೆ.
ಪರಿಣಾಮವಾಗಿ, ಸರಳವಾದ ಪರಿಹಾರವಾಗಿ, ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರ್ಯಾಯ systemd-logind ಸೇವೆಯನ್ನು ಬಳಸಲು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ ಮತ್ತು utmp ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಯಾವುದೇ ನಿಜವಾದ ಪ್ರೋಗ್ರಾಂಗಳಿಲ್ಲದ ನಂತರ, utmp ಗೆ ಬರೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. wtmp ಅನ್ನು ಬದಲಿಸಲು, systemd-journald ಅನ್ನು ಬಳಸುವ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಬರೆಯಲು ಮತ್ತು ಓದಲು API ಗಳನ್ನು ತಯಾರಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ. systemd 254 ರ ಮುಂದಿನ ಬಿಡುಗಡೆಯ ಕೋಡ್‌ಬೇಸ್ ಈಗಾಗಲೇ libsystemd ಮೂಲಕ sd-login.h API ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಥವಾ DBUS ಮೂಲಕ ಬದಲಿ utmp ಡೇಟಾವನ್ನು ಒದಗಿಸಲು ಅಗತ್ಯ ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ಮೂಲ: opennet.ru