RAIDiator OS altında bir ext3 dosya sisteminde bir dizinde yalnızca tek bir dosya için kök kullanıcı olarak izin verilmedi

Debian'a dayandığını düşündüğüm "depolama" adında bir ReadyNAS kutum var. Kök olarak ssh yapabilirim. Web sunucusunu yeniden yapılandırmaya çalışıyorum, ama sadece anlamadığım bir dosya izinleri sorunuyla karşılaşıyorum. /etc/frontview/apache/apache.pemKök olarak bile bir şey yapamam ! Aynı dizindeki diğer dosyalara kıyasla özel izinlere sahip görünmüyor ve bunlarla çalışabilirim.

storage:~# whoami 
root
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

Bu dosya hakkında dokunulmayacak kadar özel olan nedir? Ben silemiyorum. Üzerindeki izinleri değiştiremiyorum. Sahibini değiştiremem.

Dizin iyi görünüyor. Boş alanı kaldı, salt okunur olarak monte edilmedi. Aslında aynı dizindeki diğer dosyaları düzenleyebilirim.

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /

— Stephen Ostermiller
kaynak

Ayrıca çıktısını gösteriniz ls -ld /etc/frontview/apacheve df /etc/frontview/apache. Belki klasör disk alanına monte edilmiştir ro?

— Ned64

Bu bilgiyi soruya ekledim. Bana iyi geliyor. Her durumda, bu sorun olsaydı, o dizindeki diğer tüm dosyaları düzenleyebileceğimi düşünmezdim.

— Stephen Ostermiller

@RunCMD Başlığa ve etiketlere daha spesifik bilgiler ekledim. Dosya sistemi ext3 olarak listelenir, bu nedenle ext3 değişmezi destekliyor gibi görünecektir # mount:/dev/hdc1 on / type ext3 (rw,noatime)

— Stephen Ostermiller

Solaris ext3 veya ARM cpu'ları desteklemez, bu muhtemelen Solaris'e dayanmaz.

— alanc

Solaris'i bu sorudan çıkardım. Daha fazla okuma üzerine Debian Etch'e dayanabilir.

— Stephen Ostermiller

Sorunu yeni buldum. "Değişmez" özniteliği bu dosyada ayarlandı. lsgöstermiyor. Görmek için farklı bir komuta ihtiyacınız var:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

Değişmez biti kaldırdığımda, bu dosyayı düzenleyebilirim:

# chattr -i apache.pem
# touch apache.pem

— Stephen Ostermiller
kaynak

Genişletilmiş özellikleri kontrol etmenizi söylemek için "sıcak ağ soruları" nda bu soruyu tıkladım, ancak sanırım zaten yaptınız. (IDK neden GNU'nun lsözellikleri listeleme seçeneğine sahip değil. Unutuyorum, belki de bunları sorgulamak için sistem çağrısı bile taşınabilir değil, bu yüzden bunları sadece ayrı bir yardımcı programda uygulamak daha kolaydı.)

— Peter Cordes

@PeterCordes katılıyorum. Ben "biraz üzerine yazma dosyasından yükseltmeyi durdur" gibi bir şey Google Googling sonra bu bit ayarlamak eminim, ama bu yıllar önce ve açıkça bunu unuttum. Bu lsbiti gösterdiyse veya kullandığım diğer komutlardan herhangi birinin izinlerin neden reddedildiğiyle ilgili daha yararlı (ve spesifik) hata mesajlarına sahip olması güzel olurdu .

— Stephen Ostermiller

Tüm touchbildiği, denediği sistem çağrısının open("apache.pem", O_WRONLY|O_CREAT|..., 0666)başarısız olduğu EACCESS. ( strace -efile touch apache.pemDosyayla ilgili sistem çağrılarını görmek için kullanın ). Bu sistem çağrısının kılavuz sayfasının söylediği gibi , EACCESS'in birçok olası nedeni vardır ve bunların çoğu dosyanın kendisi yerine üst dizinleri içerir. Farklı dosya sistemleri ve işletim sistemleri farklı olduğu için, bir sistem çağrısının neden yaptığı hatayı neden döndürdüğünü doğru bir şekilde belirlemek için kod yazmak ...

— Peter Cordes

Her neyse, evrensel kural, bir şey başarısız olduğunda, hata kodu ( errno) için hata dizesine bakmanız ve yazdırmanızdır. (C standart kitaplık perrorişlevini veya eşdeğerini kullanma). Bu, kullanıcının sorunu hızlı bir şekilde bulması için her zaman yeterli bir ipucu olmadığı nadir durumlarda biridir, ancak çoğu zaman çok iyi çalışır. (Özellikle stracehangi işlemin hatayı ürettiği konusunda herhangi bir şüphe olması durumunda birleştirildiğinde .) Mükemmel değil, ama çok daha kötü olabilir (cf. MS Windows en iyi şekilde google'a bir hata kodu alırsınız.)

— Peter Cordes

Sadece etrafında oynuyordum chattr +ive fark rm foo(olmadan -f) istemleri: rm: remove write-protected regular file ‘foo’. Çünkü faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX, rmyazmaya karşı korumalı dosyaları kaldırmadan önce varsayılan olarak bilgi istemini gerektirir ve bu nedenle ilk etapta kontrol eder. Eğer kullanmasaydın daha hızlı bir ipucu elde ederdin rm -f. : / access(3)çekirdekten izinleri gerçekten yazma için açılıyormuş gibi kontrol etmesini ister, böylece ACL'leri ve nitelikleri alır.

— Peter Cordes