Ο Thorsten Kukuk, επικεφαλής της Future Technology Team στο SUSE (Future Technology Team, αναπτύσσει το openSUSE MicroOS και το SLE Micro), ο οποίος προηγουμένως ήταν επικεφαλής του έργου SUSE LINUX Enterprise Server για 10 χρόνια, πρότεινε να απαλλαγούμε από το αρχείο /var/run/utmp στο διανομές για την πλήρη αντιμετώπιση του προβλήματος Y2038 στο Glibc. Όλες οι εφαρμογές που χρησιμοποιούν utmp, wtmp και lastlog προτείνεται να μετακινηθούν στη λήψη μιας λίστας χρηστών που χρησιμοποιούν systemd-login.
Στις 19 Ιανουαρίου 2038, οι μετρητές χρόνου εποχής που καθορίζονται από τον τύπο time_t 32 bit θα υπερχειλίσουν. Στο Glibc, παρά την εισαγωγή του τύπου time_t 64 bit, για να διατηρηθεί η συμβατότητα με εφαρμογές χώρου χρήστη 32 bit, ο τύπος time_t 64 bit εξακολουθεί να χρησιμοποιείται σε ορισμένες περιπτώσεις σε πλατφόρμες 32 bit. Μια τέτοια περίπτωση είναι το αρχείο /var/run/utmp, το οποίο αποθηκεύει δεδομένα σχετικά με τους χρήστες που είναι συνδεδεμένοι αυτήν τη στιγμή στο σύστημα. Το πεδίο χρόνου στο utmp ορίζεται χρησιμοποιώντας μια τιμή time_t 32 bit.
Η απλή αλλαγή ενός πεδίου σε utmp από τύπο 32-bit σε τύπο 64-bit με την πάροδο του χρόνου δεν θα λειτουργήσει, καθώς αυτό θα αλλάξει το Glibc ABI (ο τύπος θα αλλάξει σε συναρτήσεις όπως login(), getutid() και utmpname() ) και διακοπή συμβατότητας με εφαρμογές που χρησιμοποιούν utmp, συμπεριλαμβανομένων w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog κ.λπ. Λόγω της πληθώρας των πιθανών παγίδων και της κοπιωδίας, η ιδέα της αντικατάστασης του μήκους bit του τύπου time_t στο utmp απορρίφθηκε από τους προγραμματιστές του Glibc. Για τον ίδιο λόγο, απορρίφθηκε η επιλογή χρήσης του διαθέσιμου χώρου στη δομή utmp για την προσθήκη ενός επιπλέον πεδίου χρόνου 64 bit.
Επιπλέον, η αλλαγή του βάθους bit του τύπου στο utmp δεν λύνει άλλα υπάρχοντα προβλήματα, τα οποία θα ήθελα επίσης να απαλλαγώ. Για παράδειγμα, η εγγραφή στο utmp απαιτεί ειδικά δικαιώματα, τα οποία απαιτούν την παραχώρηση πρόσθετων προνομίων στις διεργασίες. Ένα άλλο πρόβλημα είναι ότι η αρχιτεκτονική utmp επιτρέπει στους τοπικούς χρήστες να εκτελούν επιθέσεις DoS που διασπούν την υπηρεσία utmp μέσω χειρισμού κλειδωμάτων αρχείων, καθιστώντας αδύνατο να είμαστε σίγουροι ότι τα περιεχόμενα του utmp αντικατοπτρίζουν την πραγματική κατάσταση στο σύστημα. Προτάθηκε η χρήση μιας πρόσθετης διαδικασίας παρασκηνίου για τη διαχείριση της πρόσβασης στο utmp, αλλά για τέτοιες εργασίες υπάρχει ήδη μια διαδικασία systemd-logind και δεν συνιστάται η έναρξη άλλης εξειδικευμένης διαδικασίας (οι εφαρμογές θα πρέπει να μεταφέρουν δεδομένα σε δύο χειριστές ταυτόχρονα) .
Ταυτόχρονα, ακόμη και κατά την επίλυση του προβλήματος με επιθέσεις DoS, το περιεχόμενο του utmp παραμένει μόνο ενημερωτικό, χωρίς να εγγυάται την αντανάκλαση της πραγματικότητας. Για παράδειγμα, διαφορετικοί εξομοιωτές τερματικού και πολυπλέκτης αντικατοπτρίζουν την κατάστασή τους διαφορετικά - η εκτέλεση πέντε τερματικών GNOME θα έχει ως αποτέλεσμα έναν χρήστη να αντικατοπτρίζεται στο utmp, ενώ η εκτέλεση πέντε τερματικών konsole ή xterm στο KDE θα έχει ως αποτέλεσμα έξι. Ομοίως, η συμπεριφορά της οθόνης και του tmux διαφέρει, στην πρώτη περίπτωση κάθε περίοδος σύνδεσης υπολογίζεται ως ξεχωριστός χρήστης και στη δεύτερη μόνο ένας χρήστης αντικατοπτρίζεται για όλες τις συνεδρίες.
Ως αποτέλεσμα, ως η απλούστερη λύση, προτείνεται η μεταφορά όλων των εφαρμογών για χρήση της ήδη υπάρχουσας εναλλακτικής υπηρεσίας systemd-logind και, αφού δεν υπάρχουν πραγματικά προγράμματα που έχουν πρόσβαση στο utmp, να σταματήσει η εγγραφή στο utmp. Για την αντικατάσταση του wtmp, προτείνεται να προετοιμαστούν API για εγγραφή και ανάγνωση πληροφοριών σχετικά με χρήστες που χρησιμοποιούν το systemd-journald. Η βάση κώδικα για την επόμενη έκδοση του systemd 254 περιλαμβάνει ήδη τις απαραίτητες λειτουργίες για την παροχή αντικατάστασης δεδομένων utmp μέσω του libsystemd χρησιμοποιώντας το sd-login.h API ή μέσω DBUS.
Πηγή: opennet.ru