Docker Engine 29.8 --umask bayrağı, exec oturumlarındaki ve healthcheck'lerdeki yetki kaymasını düzeltiyor

Docker Engine 29.8 ile yerleşik umask ayarı geliyor

3 Eylül 2026'da yayımlanan Docker Engine 29.8.0, HostConfig.Umask ayarını ve docker run ile docker create için buna karşılık gelen --umask bayrağını ekliyor. dev.to'daki bir uygulama deneyimi yazısında referans verilen belgelere göre bu ayar, container'ın ana sürecini, exec oturumlarını ve healthcheck'leri yönetiyor — ve bu genişlik, değişikliğin asıl amacı.

Eski çözümün geride bıraktığı boşluk

Daha önce bir container'ın umask değerini kontrol etmenin kabul gören yolu bir entrypoint script'iti: mask'i ayarla, sonra gerçek uygulamaya geç. Bu, PID 1'i düzeltir ve PID 1'in çocukları bu değeri miras alır. Sorun şu: docker exec ile başlatılan bir süreç, runtime tarafından doğrudan container'ın namespace'lerine bağlanır — PID 1'in çocuğu değildir ve umask değerini asla miras almaz. Healthcheck komutları da bu kalıtım zincirinin dışında kalır.

Dev.to yazarı farkı ölçmüş. umask 027 ayarlayan bir entrypoint ile ana süreç istendiği gibi 640 modunda dosyalar üretirken, exec oturumunda oluşturulan dosyalar 644'te kaldı. Healthcheck probları da aynı şekilde, tek bir deneme yerine iki saniyelik aralıklarla tekrarlanan çalıştırmalarda tutarlı biçimde aynı sonucu verdi. Script'i --umask 027 ile değiştirmek üç yerde de 640 verdi ve sonuçlar ardışık kontrollerde kararlı kaldı.

Referans olması için: yazıda, umask ayarlanmadığında Alpine'nin varsayılanlarının 644 dosya ve 755 dizin ürettiği; --umask 027'nin 640 ve 750 verdiği; --umask 000'ın ise 666 dosya verdiği belirtiliyor.

Doğrulama katı — ta ki öyle olmayana kadar

Bayrak, girdisini Go'nun strconv.ParseUint fonksiyonuyla işaretsiz tamsayı olarak ayrıştırıyor; bu yüzden 099, -1 gibi değerler, u=rwx gibi sembolik gösterimler veya boş bir dize, container henüz oluşturulmadan reddediliyor ve hatalar gerçek sorunun işaret ediyor.

Yazarı şaşırtan ise sızan şeyler oldu. Bir umask, setuid, setgid ve sticky bit'leri için baştaki dördüncü bir oktal basamak taşıyabilir ve Docker'ın yardım metni bir aralık belirtmiyor. 1777 verilmesi sessizce kabul ediliyor ama 0777 olarak uygulanıyor; 2027 ve 4027 de aynı şekilde 0027'ye düşüyor. Daemon log'unda uyarı yok, istemciye dönen hata da yok; dolayısıyla başka bir yerden kopyalanan bir değer, özel bit önekini sessizce kaybedebilir.

Bir de script tehlikesi var: HostConfig.Umask için format dizesiyle docker inspect, değeri düz bir ondalık tamsayı olarak döndürüyor — oktal 027 için 23 — dolayısıyla literal 027 dizesini arayan izleme script'leri asla eşleşme bulamıyor.

Yeni bayrağın ulaşamadığı yerler

Dev.to testlerinden iki sınırlama öne çıkıyor. docker update'te umask seçeneği yok, yani çalışan bir container'ın mask'i oluşturulduktan sonra değiştirilemiyor; container'ın yeniden oluşturulması gerekiyor. Ayrıca Docker Compose (v5.1.1'de kontrol edildi), service tanımındaki umask anahtarını bilinmeyen özellik olarak reddediyor; bu da Compose tarafından yönetilen servisleri entrypoint veya command override'larına bağımlı bırakıyor — ve özelliğin varlık amacı olan exec ve healthcheck boşluğuna karşı hâlâ açık.

Yazıya göre diğer her şey duyurulduğu gibi çalıştı: --umask 027, --user 1000:1000 ile birlikte kullanıldığında yine 640 üretti, bind mount üzerinden yazılan dosyalar container içindekiyle aynı modu host'ta taşıdı, --umask 077 ile bir named volume 600 verdi ve aynı container'a yapılan on paralel exec oturumunun tümü sapma olmadan 0027 bildirdi; bu da daemon'un ayarı eşzamanlı erişim altında kararlı biçimde uyguladığına işaret ediyor.

Neden önemli

Bu tutarsızlık tam da ön plandaki süreç doğru davrandığı için gözden kaçması kolaydı — entrypoint'i yazan kişi, çalıştığını görebildiği şeyi test etti. Başarısızlıklar yalnızca bir deploy script'inin veya izleme sidecar'ının, politikanın öngördüğünden daha geniş yetkili bir dosyayla karşılaştığı yerde ortaya çıktı; umask'lerin var olma amacını önlediği sessiz güvenlik kayması tam da budur. Yeni bayrak, politikayı ilk kez PID 1 genişliğinde değil container genişliğinde yapıyor; bu, çok kiracılı veya hassas iş yükleri çalıştıran herkes için anlamlı bir sağlamlaştırma adımı. Ancak Compose desteği gelene kadar ve özel bit öneklerinin sessizce kırpılması göz önüne alındığında, ekipler geçirilen değerin uygulanan değer olduğunu varsaymak yerine fiilen geçerli olan mask'i doğrulamalı.