Umask 077'nin dezavantajları?


15

077 kısıtlayıcı bir umask için eksileri nelerdir? Çok sayıda dağıtım (Red Hat hariç hepsine inanıyorum?) / Etc / profile'de yapılandırılmış 022'lik varsayılan bir umask'a sahiptir. Bu, birden fazla kullanıcının eriştiği masaüstü olmayan bir sistem için çok güvensiz görünüyor ve güvenlik endişe verici.

İlgili bir notta, Ubuntu'da, kullanıcıların ev dizinleri de 755 izinle oluşturulur ve yükleyici, kullanıcıların dosyaları paylaşmasını kolaylaştırmak için olduğunu belirtir. Kullanıcıların dosyaları paylaşmak için el ile rahatça izin ayarlamalarını varsayarsak, bu bir sorun değildir.

Başka ne dezavantajları var?


izinleri etiketleri için 'umask' daha fazla gibi görünüyor ... imo
xenoterracide

Bir soru için en fazla 5 etiketiniz olabilir, neden bu konuda kavga ediyorsunuz? :) umask etiketi eklendi.
Warren Young

@warren çünkü her uygun isim için etiketlere ihtiyacımız olduğunu düşünmüyorum. unix'te konuşma izinleri umask eklemeniz gerekir.
xenoterracide

Yanıtlar:


15

022 işleri kolaylaştırır. 077 işleri daha az kolaylaştırır, ancak koşullara ve kullanım profiline bağlı olarak, kullanmak zorunda kalmaktan daha az uygun olmayabilir sudo.

Bundan elde sudoettiğiniz gerçek, ölçülebilir güvenlik avantajının, kendinize ve kullanıcılarınıza uyguladığınız acı düzeyine kıyasla önemsiz olduğunu iddia ediyorum . Bir danışman olarak, görüşlerim için puan verdim sudove sayısız sudokurulumu kırmaya zorlandım ve henüz 15 saniyeden fazla sürmem gerekiyor. Çağrınız.

Hakkında bilmek umaskiyi, ama "tam kahvaltı" sadece tek bir Mısır pul olduğunu. Belki kendinize sormalısınız "Varsayılan yapılandırmalarla uğraşmaya başlamadan önce, tutarlılığı kurulumlar boyunca sürdürülecek ve kararsız olan kişilere belgelenecek ve haklı gösterilecek, bu ne alacak ben mi?"

Umask ayrıca bireysel kullanıcılar tarafından kabuk başlatma dosyalarında ( ~/.bash*) ayarlanabilen bir bash yerleşiktir , bu yüzden gerçekten kolayca zorlayamazsınız umask. Bu sadece bir varsayılan. Başka bir deyişle, sizi çok fazla satın almıyor.


2

En belirgin dezavantajı, paylaşılan bir dizinde dosya / dizin oluşturmaya başladığınız ve diğer kullanıcıların bunlara erişmesini beklediğiniz zamandır.

Tabii ki, sadece tüm kullanıcılar tarafından paylaşılması gereken şeyler yapmadan önce doğru umask'ı ayarlamayı unutmamak gerekir.

Başka bir uyarı (gerçekten bir dezavantaj değil, bir kez farkında olduğunuzda), yerel programlar, yakut taşlar, python yumurtaları (işletim sistemlerini açıkça yönetmez), yapılandırma dosyaları oluşturma ve benzeri gibi sudo şeyler yapmaya başladığınızdır.

Umask'ın sudo oturumu tarafından miras alındığı için sorun yaşarsınız, bu nedenle yalnızca kök oluşturduğunuz dosyalara / dizinlere erişebilir. sudo, umask'i istediğiniz gibi otomatik olarak ayarlayacak şekilde yapılandırılabilir: bu soru superuser.com'da ele alınmıştır .


ve ikinci sebep, su -kökün farklı bir
umask'a

1
@ xenoterracide: iyi sudo su -çalışıyor. Ubuntu, MacOSX gibi, giriş yapabileceğiniz bir köke inanmıyor. Şahsen, çoğu zaman kök komutları için "Simon Says" gibi bir şey söylemek zorunda kalıyorum.
David Thornley

@xenoterracide ha? Ne demek istiyorsun? sudo ve su, farklı bir umask köküne izin verir. @David sudo su yerine sudo -i kullanabilirsiniz -
zarkdav

1
@xenoterracide: Aslında root komutunu kullanmak yanlış pencereye bir şey yazacağım anlamına geliyor. "Sudo" kullanmak, bunun root tarafından yürütülmesini istediğimi belirtmem gerektiği anlamına gelir. Kök hesabı olduğunu çok iyi biliyorum, bu yüzden sahte güvenlik duygusunun nereden geldiğini göremiyorum. Sadece bir küçük ritüel (ellerimde oturmak gibi) kök olarak ölümcül bir şekilde aptalca bir şey yapmam olasılığını azaltıyor.
David Thornley

1
sudo ve su, herhangi bir komut gibi bir araçtır. Duyguları fayda ile karıştırmaya gerek yoktur. sudo, esnek yapılandırma, denetim ve kullanılabilirlik sağlar. Tabii ki, çeşitli olasılıkları bilmek ve faydaları tanımak için aslında onlara ihtiyaç duymak gerekir. Bahsettiğiniz bu "yanlış güvenlik duygusu" Ubuntu "kök hesabı devre dışı" politikasına daha uygun bir şekilde hedeflenmelidir. Bir araç ile bir politika arasındaki fark budur. Politikaya karşı iyi argümanlar yapılabilir. Bir kişinin bir politikayı kabul etmediği için bir aracın kullanışlılığını reddetmek oldukça yanlıştır.
zarkdav

1

Diğer kullanıcıların birbirlerinden neler görebileceğini kontrol etmeye çalışıyorsanız Umask uygun olmaz. Ancak, bunlara erişmek için izin verilen noktaya duyarlı çok sayıda dosyanız varsa ve onlarla çalışıyorsanız, insanların istediklerini görmelerine izin vermekten daha az rahatsız edici / riskli ise, 077'lik bir umasktan daha iyi bir fikir olacaktır.

Yönettiğim bir dosya sunucusunda bazı hassas dosyalarım var. Kısıtlayıcı bir umask ayarlamak sonra periyodik bir komut dosyası, belki bazı klasörlerdeki öğeler için daha spesifik izinler ayarlamak için bir cron işi benim için ideal bir çözüm olacağını düşünüyorum. Bunu kurduğumda buraya geri göndereceğim ve nasıl çalıştığını size bildireceğim.

@ [Çocuklar sudo bashing] Bunun için yeni bir iş parçacığı başlatın, kendi birkaç iş parçacığı alabilir ve bu iş parçacığı umask hakkında.


1

Kendi kurulum sistemlerini kullanan üçüncü taraf uygulamaların, sistem varsayılan umask hakkında yerleşik varsayımları olabilir.

Pratik bir örnek olarak, umask'ı 077 olarak ayarlanmış bir sistemde bir Oracle 10 veritabanını güncelledikten sonra, aynı sistemdeki uygulamalar veritabanına erişemedi ... çünkü veritabanı istemcileri için gerekli kütüphaneler ve kütüphaneler dizinler yerlerinde, şimdi sadece oraclekullanıcılara erişebilsin diye korundu , ki işlerin nasıl çalışması gerektiği belli değildi.

Oracle güncelleyici işleminin, istemci kitaplıklarının izinlerinin diğer kullanıcıların bunları kullanmasına izin vermediğine dikkat etmediği, bunun yerine güncelleyici tarafından eklenen dosyaların umask 022 ile oluşturulacağı ve bu nedenle kullanılabilir olduğu varsayımına dayanıldığı ortaya çıktı. varsayılan olarak. chmod -R a+rXUygun dizinler için birkaç makul komuttan sonra , her şey yolundaydı.

Verilen, bu oraclehesabın standart umask 022 ile özel bir sistem hesabı olarak ele alınması ve umask 077'nin sadece giriş yapabilen kullanıcı hesaplarıyla kısıtlanmasıyla önlenebilirdi ... ama bunun battaniyenin "sertleşmesinin nasıl iyi bir örneği olduğunu düşünüyorum. "kararların öngörülemeyen yan etkileri olabilir.

.rpmve .debpaketler, içerdikleri dosyalar için açık izin bilgileri taşırlar, bu nedenle genellikle bu tür hata riski yoktur.


0

Bu çizgimde benim ~/.zshrc

umask 0077

küresel olarak ayarlamak muhtemelen iyi bir fikir değildir, ancak rc dosyanızda varsayılan olarak ayarlamak muhtemelen zarar görmeyecek ve hatta /etc/skel/.rcdosyada varsayılan olarak ayarlanmayacaktır . sistem çapında olsa da sorunlara neden olacaktır.


0

Bir sunucuda sorunlara neden olur; örneğin, farklı kullanıcılardan gelen dosyalara erişmeye çalışan farklı kullanıcılar olarak çalışan birden çok uygulama olduğunda. Apache okuma yapılandırma dosyaları veya pi delik okuma dnsmasq.conf gibi. Açıkça ayarlanmayan tek tek ev dizinleri gibi faydalanabilecek kullanıcılar üzerinde çalıştırmanız yeterlidir /etc/profile.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.