SUSE'de, Glibc'deki Y2038 sorununu çözmek için utmp kullanmayı bırakmanızı önerirler.

Y2038

2038 yılının sorunu, yazılımın bir kısmının o yıl içinde arızalanmasına neden olabilir. Sorun, zamanın POSIX tabanlı temsilini kullanan programları etkiler.

Thorsten Kukuk, takım Lideri SUSE Future Technology'den (Future Technology Team, openSUSE MicroOS ve SLE Micr'i geliştirir), daha önce SUSE LINUX Enterprise Server projesine 10 yıl liderlik etmiş, /var/run/utmp dosyasından kurtulmayı önerdi dağıtımlarda Glibc'deki Y2038 sorununu tam olarak ele almak için.

Bununla utmp, wtmp ve lastlog kullanan tüm uygulamaların taşınması önerilir. systemd-logind kullanan kullanıcıların bir listesini almak için.

19 Ocak 2038'de zamanlayıcılar taşacak belirtilen süre 32-bit time_t tipine göre. Glibc'de, 64-bit time_t türünün tanıtılmasına rağmen, 32-bit kullanıcı alanı uygulamalarıyla uyumluluğu korumak için, 32-bit time_t türü bazı durumlarda 64-bit platformlarda hala kullanılmaktadır.

Örneğin x86-64'te glibc ile utmp/utmpx ile ilgili iki ana sorun vardır:

Zaman için 32'de taşacak olan 2038 bitlik bir time_t alanı kullanılır.
Bir DoS saldırısına izin veren tasarım sorunları var (utmp/wtmp engelleme ayrıcalığı olmayan bir kullanıcının hizmeti reddetmesine izin verir)
Glibc geliştiricileri tarafından ikinci sorunun analizi, utmp/utmpx erişimini işlemek için ek bir arka plan programının gerekli olacağını gösterdi.

Daha bir çok sorun olsada...

Böyle bir durum /var/run/utmp dosyasıdır., o anda sisteme bağlı olan kullanıcılarla ilgili verileri saklar. utmp'deki zaman alanı, 32 bitlik bir time_t değeri kullanılarak ayarlanır.

Bahsedilen, utmp'deki bir alanı zaman içinde 32 bit türden 64 bit türe değiştirmek işe yaramaz, çünkü bu, Glibc ABI'yi değiştirecek (login(), getutid() ve utmpname() gibi işlevlerde tür değişecek) ve w, who, uptime, login, su, sudo, useradd dahil olmak üzere utmp kullanan uygulamalarla uyumluluğu bozacaktır. , systemd, sysvinit, tcsh, xterm ekran yöneticileri, emacs, openssh, qemu, samba, rsyslog, vb.

Potansiyel tuzakların ve çalışkanlığın bolluğu nedeniyle, geliştiricileri Glibc, time_t türünün bit uzunluğunu utmp ile değiştirme fikrini reddetti. Aynı nedenle, utmp yapısındaki kullanılabilir alanı, ek bir 64 bitlik zaman alanı eklemek için kullanma seçeneği kaldırılmıştır.

Ayrıca, utmp'deki türün bit derinliğini değiştirmek mevcut diğer sorunları çözmez, örneğin utmp'ye yazmak, işlemlere ek ayrıcalıklar verilmesini gerektiren özel izinler gerektirir. Başka bir sorun da, utmp mimarisinin, yerel kullanıcıların, dosya kilitlerini değiştirerek utmp hizmetini kıran DoS saldırıları gerçekleştirmesine izin vererek, utmp içeriğinin sistemin gerçek durumunu yansıttığından emin olmayı imkansız hale getirmesidir.

Utmp'ye erişimi işlemek için ek bir arka plan işlemi kullanılması önerildi, ancak bu tür görevler için zaten bir systemd-logind işlemi vardır ve başka bir özel işlemin başlatılması önerilmez (uygulamaların aynı anda iki denetleyiciye veri aktarması gerekir).

Aynı zamanda, sorunu DoS saldırılarıyla çözse bile, utmp'nin içeriği, gerçekliğin bir yansımasını garanti etmeden yalnızca bilgilendirici kalır.

Örneğin, farklı uçbirim öykünücüleri ve çoklayıcılar durumlarını farklı şekilde yansıtırlar: beş GNOME uçbirimi çalıştırmak bir kullanıcının utmp'de yansıtılmasına neden olurken, KDE'de beş konsole veya xterm uçbirimi çalıştırmak altı ile sonuçlanacaktır. Benzer şekilde, ekran ve tmux'un davranışı farklıdır, ilk durumda her oturum ayrı bir kullanıcı olarak sayılır ve ikinci durumda tüm oturumlar için yalnızca bir kullanıcı yansıtılır.

Sonuç olarak, en basit çözüm olarak, tüm uygulamaların systemd-logind hizmetini kullanması için port edilmesi önerilir alternatif zaten var ve hiçbir gerçek program utmp'ye erişmediğinde, utmp'ye yazmayı bırakın. Wtmp'yi değiştirmek için, systemd-journald kullanan kullanıcılar hakkında bilgi yazmak ve okumak için API'lerin hazırlanması önerilir.

Son olarak, bir sonraki sürüm için kod tabanının olduğunu belirtmekte fayda var. systemd 254 zaten gerekli işlevleri içerir DBUS aracılığıyla sd-login.ho API'sini kullanarak libsystemd aracılığıyla yedek utmp verileri sağlamak için.

Bu konuda daha fazla bilgi edinmekle ilgileniyorsanız, ayrıntılara danışabilirsiniz. Aşağıdaki bağlantıda.


Yorumunuzu bırakın

E-posta hesabınız yayınlanmayacak. Gerekli alanlar ile işaretlenmiştir *

*

*

  1. Verilerden sorumlu: AB Internet Networks 2008 SL
  2. Verilerin amacı: Kontrol SPAM, yorum yönetimi.
  3. Meşruiyet: Onayınız
  4. Verilerin iletilmesi: Veriler, yasal zorunluluk dışında üçüncü kişilere iletilmeyecektir.
  5. Veri depolama: Occentus Networks (AB) tarafından barındırılan veritabanı
  6. Haklar: Bilgilerinizi istediğiniz zaman sınırlayabilir, kurtarabilir ve silebilirsiniz.