400 iznine sahip bir dosya neden root tarafından yazılabilir, ancak kullanıcı tarafından salt okunur olarak görülüyor?

Ayrıcalıksız bir kullanıcı olarak bir dosya oluşturur ve izinler modunu olarak değiştirirsem 400bu kullanıcı tarafından salt okunur, doğru olarak görünür:

$ touch somefile
$ chmod 400 somefile
$ [ -w somefile ] && echo rw || echo ro
ro

Herşey iyi.

Ama sonra kök gelir:

# [ -w somefile ] && echo rw || echo ro
rw

Ne halt? Elbette, root salt okunur dosyalara yazabilir, ancak bir alışkanlık yapmamalıdır: En İyi Uygulama, yazma izni bitini test edebilmem gerektiğini dikte eder ve eğer değilse, o zaman ayarlanır bir sebepten ötürü.

Sanırım neden bu olduğunu anlamak istiyorum ve yazma biti ayarlanmamış bir dosyayı test ederken nasıl yanlış bir dönüş kodu alabilirim ?

permissions test readonly

— Zengin
kaynak

btw Hem RHEL6 ( 4.1.2(1)-release) hem de RHEL7 ( ) kullanıyorum 4.2.46(2)-release.

— Zengin

"En İyi Uygulama, yazma izni bitini test edebilmem gerektiğini dikte ederdi ve eğer değilse, bir sebepten dolayı bu şekilde ayarlandı." - Aslında, en iyi uygulama "şeyleri root olarak çalıştırma" dır. Kök olarak çalışıyorsanız, izin kontrollerini atlamaya karar verdiniz. Bu izin denetimlerini kullanıcı alanında el ile yeniden uygulamak bir felaket reçetesidir .

— Kevin

@Kevin Eğer ayrıcalıklı olmayan şeyler çalıştırabilirsen senin için iyi. Bu, /etc/dhcp/dhcpd.confkökün sahip olduğu manipülasyon içindir . Satıcı tarafından sağlanan kullanıyorum dhcpd. Tamamen felaket, ha? Dosya RCS kontrol edilir, ben kullanımını otomatik hale ediyorum rcsdiff, cive cobiz var çünkü operatörlere ihtiyaç için ... çalışmalarını sağlayacaktır. İzin biti denetimi ( -wayrıntılı olarak açıklandığı gibi test(1)), ci -ubir dosyayı salt okunur bırakan temelde çalışan ilk hata satırı olacaktı . Ben oradan ayrılıp doğrudan gidip rcsdiff -qkontrol ediyorum $?. Çok dhcpdmu saçma ? Sahibi olacaktı dhcpd.

— Zengin

Bu bir var potansiyel çekirdekte diğeri userspace tane: Artık izinleri çeklerin iki farklı uygulamaları var çünkü felaket. Daha da kötüsü, bu uygulamalar aynı sonuçları üretmek için tasarlanmamıştır, bu yüzden onları birbirleriyle test edemezsiniz. Artık erişim için birbirinden bağımsız olarak kilitlenmesi ve emniyete alınması gereken iki yolunuz var.

— Kevin

@Kevin Elbette, aynı sonuçları üretmiyorlar ve (managesdeki ayrıntıların azlığına rağmen) amaçlanmadılar, ancak açıkça yazma izni bitini kontrol etmek istiyorum ; ve için Elyordamsayfalarının bashve testbu ne inanmak götürdü [ -wiçindir.

— Zengin

Yanıtlar:

test -waka [ -wdosya modunu kontrol etmez. Yazılabilir olup olmadığını kontrol eder. Kök için öyle.

$ help test | grep '\-w'
  -w FILE        True if the file is writable by you.

Test edeceğim yol, stat(1)(" %a Sekizlik erişim hakları") çıktısına karşı bitsel bir karşılaştırma yapmak olacaktır .

(( 0$(stat -c %a somefile) & 0200 )) && echo rw || echo ro

Alt kabuğun ön ekli olması $(...)gerektiğini unutmayın, 0böylece çıktısı statsekizlik olarak yorumlanır (( ... )).

— Patrick
kaynak

Kısa ve öz olduğun için teşekkürler. İyi kullanımı (( ... & ... )). Bir yazım hatası düzeltildi :-)

— Zengin

Bunu yapın 3 ... ifGerekli değil, sekizli izin çıkışı %adeğil %dve çıkışını sekizlik olarak yorumlamak için (( ... ))önek 0gereklidir stat.

— Zengin

@ Patrick benim man stat"ondalık olarak% d cihaz numarası" diyor, ancak istediğimiz "erişim hakları" dır , değil mi? 0 önekine ihtiyaç duyduğunuz nokta iyi yapılmış, ancak sanırım orada saklamalıyız :).

— sourcejedi

stat -c 0%a...

— sourcejedi

@sourcejedi ack, haklısın. Nedense% d ondalık erişim hakkı olduğunu düşünüyordum. Düzenlemeyi geri yükledi. teşekkürler :-)

— Patrick

Sanırım ne yaptığını yanlış anladın -w. Dosyanın "Yazma izinleri" olup olmadığını kontrol etmez, dosyayı çağıran kullanıcı tarafından yazılabilir olup olmadığını kontrol eder .

Daha spesifik olarak, çağrı access(2)veya benzeri.

Örneğin, bir komut dosyasında if [ -w /etc/shadow ]varsa strace, komut dosyasında çalışırsanız,

faccessat(AT_FDCWD, "/etc/shadow", W_OK)

Yana root0 döndürür sonra dosyaya yazabilir.

örneğin, normal bir kullanıcı olarak:

faccessat(AT_FDCWD, "/etc/shadow", W_OK) = -1 EACCES (Permission denied)

Kök olarak

faccessat(AT_FDCWD, "/etc/shadow", W_OK) = 0

Bu, makinemde /etc/shadowizin olmasına rağmen 000.

---------- 1 root root 4599 Jan 29 20:08 /etc/shadow

Şimdi yapmak istediğiniz şey ilginçleşiyor ve o kadar basit değil.

Basit izinleri kontrol etmek istiyorsanız, lsçıkışı kontrol edin veya arayın statveya benzeri. Ancak, ACL'lerin bu izinleri aşabileceğini unutmayın. Bir dosyanın izni 400 olduğu için yazılabilir olmasını engellemez ...

— Stephen Harris
kaynak

Hayır, "yanlış anlama" şu sayfalar için yanlış sayfaları okuyor -w: test(1)açık: "DOSYA var ve yazma izni verildi" değil, " geçerli kullanıcı tarafından dosya yazılabilir ". İzinleri veya ACL'leri geçersiz kılma hakkında hiçbir şey yok . bash(1)is cagey: "Dosya varsa ve yazılabilirse doğrudur ." ksh(1)shenanigans'a ince bir ipucu yapar: "-w file // Dosya varsa ve geçerli işlem tarafından yazılabilirse true ." zsh(1)izin verir test(1), zshmisc(1)olarak ifade edilir ksh(1)ve zshexpn(1)bazı ilginç izinlere dayalı globbing ayrıntılar. csh(1)komik bir şekilde kısa: "Yazma erişimi".

btw: Patrick'in cevabını kabul ettim, 1. başlangıç sorusunu yeterince cevaplamadığınız için: yazma biti ayarlanmamış bir dosyayı test ederken nasıl yanlış bir dönüş kodu alabilirim? ve 2. sinsi liderlik nedeniyle manajları yanlış anladım.

— Zengin

@Rich Bunu okuma şeklimde, yorumlarınızın da biraz sinsi olduğunu düşünüyorum. Yazdığınız her şeyin yanlış olduğunu söylemiyorum, sadece daha kibar bir şekilde ifade edilirse muhtemelen daha iyi geçeceğini söyledi.

— David Z

"Sanırım yanlış anladın ..." çok kötü değil. Ancak yanıtınız% 100 keskin.

— barbekü

@Rich Ayrıca, manajlar berrak olmasa da, Stephen, " -w ne yaptığını yanlış anladığını " ve manajların söylediği şeyleri değil , eski durumun nerede göründüğünü, bu yüzden soruyu söylediğini söyledi

— Sebi

Kök kullanıcı istediği gibi yapabilir, "normal" dosya izinleri sınırlama yoktur. Herhangi bir eXecute izni olmadan doğrudan düz bir dosya yürütmez, sadece temel hedef uygulamalarına karşı biraz sigorta için.

— vonbrand
kaynak