Autorizzazione negata per un solo file in una directory come utente root su un filesystem ext3 nel sistema operativo RAIDiator

Ho un box ReadyNAS chiamato "storage" che credo sia basato su Debian. Posso parlarci come root. Sto cercando di riconfigurare il server web, ma sto riscontrando un problema con le autorizzazioni dei file che non capisco. Non posso fare nulla con /etc/frontview/apache/apache.pemnemmeno come root! Non sembra avere autorizzazioni speciali rispetto ad altri file nella stessa directory e posso lavorare con quelli.

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

Cosa c'è di così speciale in questo file da non poterlo toccare? Non posso cancellarlo. Non riesco a modificare le autorizzazioni su di esso. Non posso cambiarne il proprietario.

La directory sembra andare bene. Ha spazio, non è montato in sola lettura. In effetti posso modificare altri file nella stessa directory.

# 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
fonte

Mostra anche l'output di ls -ld /etc/frontview/apachee df /etc/frontview/apache. Forse la cartella si trova su uno spazio su disco montato ro?

— Ned64,

Ho aggiunto queste informazioni alla domanda. Mi sembra tutto a posto. In ogni caso, se quello fosse il problema, non penserei di poter modificare tutti gli altri file in quella directory.

— Stephen Ostermiller,

@RunCMD Ho aggiunto informazioni più specifiche al titolo e ai tag. Il filesystem è elencato come ext3, quindi ext3 sembra supportare immutabile # mount::/dev/hdc1 on / type ext3 (rw,noatime)

— Stephen Ostermiller,

Solaris non supporta ext3 né ARM CPU, quindi probabilmente non è basato su Solaris.

— alanc,

Ho rimosso Solaris dalla domanda. Su ulteriori letture potrebbe essere basato su Debian Etch.

— Stephen Ostermiller,

Ho appena trovato il problema. L'attributo "immutabile" è stato impostato su quel file. lsnon lo mostra. È necessario un comando diverso per vederlo:

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

Una volta rimosso il bit immutabile, posso modificare quel file:

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

— Stephen Ostermiller
fonte

Ho fatto clic su questa domanda nelle "domande sulla rete attiva" per dirti di controllare gli attributi estesi, ma suppongo che tu l'abbia già fatto. (IDK perché GNU lsnon ha un'opzione per elencare gli attributi. Ho dimenticato, ma forse anche la chiamata di sistema per interrogarli non è portatile, quindi probabilmente è stato più semplice implementarli in un'utilità separata.)

— Peter Cordes

@PeterCordes Sono d'accordo. Sono sicuro di aver impostato quel bit dopo aver cercato su Google qualcosa come "interrompere l'aggiornamento dalla sovrascrittura del file", ma è stato anni fa e ho chiaramente dimenticato di farlo. Sarebbe bello se lsmostrasse quel bit, o se qualcuno degli altri comandi che ho usato avesse messaggi di errore più utili (e specifici) sul perché le autorizzazioni fossero state negate.

— Stephen Ostermiller,

Tutti touchsanno che la chiamata di sistema con cui ha tentato ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) non è riuscita EACCESS. (Utilizzare strace -efile touch apache.pemper vedere le chiamate di sistema relative ai file che effettua). Come dice la pagina man per quella chiamata di sistema , ci sono molte possibili ragioni per EACCESS, e molte di esse coinvolgono directory padre piuttosto che il file stesso. Scrivere un codice per dedurre con precisione il motivo per cui una chiamata di sistema ha restituito l'errore che ha commesso sarebbe estremamente difficile, dato che file system e SO diversi sono diversi ...

— Peter Cordes,

Comunque, la convenzione universale è che quando qualcosa fallisce, cerchi la stringa di errore per il codice di errore ( errno) e lo stampi. (Utilizzando la perrorfunzione di libreria standard C o equivalente). Questo è uno dei rari casi in cui non sempre è sufficiente un suggerimento per l'utente di trovare rapidamente il problema, ma il più delle volte funziona molto bene. (Soprattutto se combinato con stracenel caso in cui ci sia qualche dubbio su quale operazione abbia generato l'errore.) Non è perfetto, ma potrebbe essere molto peggio (vedi MS Windows dove al massimo ottieni un codice di errore su Google.)

— Peter Cordes

Era solo giocare con chattr +i, e ho notato che rm foo(senza -f) richieste: rm: remove write-protected regular file ‘foo’. A causa faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX richiede rmdi richiedere per impostazione predefinita prima di rimuovere i file protetti da scrittura e, per questo motivo, controlla in primo luogo. Quindi avresti avuto un grande indizio più veloce se non avessi usato rm -f. : / access(3)chiede al kernel di controllare le autorizzazioni come se si stesse davvero aprendo per la scrittura, quindi raccoglie ACL e attributi.

— Peter Cordes,