Odmowa dostępu tylko dla jednego pliku w katalogu jako użytkownik root w systemie plików ext3 w systemie RAIDiator

Mam pudełko ReadyNAS o nazwie „pamięć”, które moim zdaniem opiera się na Debianie. Mogę ssh w nim jako root. Próbuję ponownie skonfigurować serwer WWW, ale napotykam problem z uprawnieniami do plików, którego po prostu nie rozumiem. Nie mogę nic zrobić, /etc/frontview/apache/apache.pemnawet jako root! Nie ma żadnych specjalnych uprawnień w porównaniu z innymi plikami w tym samym katalogu i mogę z nimi pracować.

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

Co jest takiego specjalnego w tym pliku, że nie można go dotknąć? Nie mogę tego usunąć. Nie mogę zmienić uprawnień do tego. Nie mogę zmienić właściciela.

Katalog wydaje się być w porządku. Zostało mu miejsce, nie jest montowany tylko do odczytu. W rzeczywistości mogę edytować inne pliki w tym samym katalogu.

# 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
źródło

Pokaż także dane wyjściowe ls -ld /etc/frontview/apachei df /etc/frontview/apache. Może folder jest na zamontowanym miejscu na dysku ro?

— Ned64

Dodałem tę informację do pytania. Dla mnie wszystko wygląda dobrze. W każdym razie, gdyby to był problem, nie sądziłbym, że mógłbym edytować każdy inny plik w tym katalogu.

— Stephen Ostermiller

@RunCMD Dodałem bardziej szczegółowe informacje do tytułu i tagów. System plików jest wymieniony jako ext3, więc wydaje się, że ext3 obsługuje niezmienne # mount::/dev/hdc1 on / type ext3 (rw,noatime)

— Stephen Ostermiller

Solaris nie obsługuje procesorów ext3 ani ARM, więc prawdopodobnie nie jest oparty na systemie Solaris.

— alanc

Usunąłem Solaris z pytania. Przy dalszym czytaniu może być oparty na Debian Etch.

— Stephen Ostermiller

Właśnie znalazłem problem. W tym pliku ustawiono atrybut „niezmienny”. lsnie pokazuje tego. Aby zobaczyć, potrzebujesz innego polecenia:

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

Po usunięciu niezmiennego bitu mogę edytować ten plik:

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

— Stephen Ostermiller
źródło

Kliknąłem to pytanie w „gorących pytaniach sieciowych”, aby powiedzieć, aby sprawdzić rozszerzone atrybuty, ale myślę, że już to zrobiłeś. (IDK, dlaczego GNU lsnie ma opcji wylistowania atrybutów. Zapomniałem, ale może nawet systemowe wywołanie zapytania do nich nie jest przenośne, więc prawdopodobnie łatwiej było po prostu zaimplementować je w oddzielnym narzędziu.)

— Peter Cordes

@PeterCordes Zgadzam się. Jestem pewien, że ustawiłem to trochę po Googlingu, na przykład „przestań aktualizować z nadpisywania pliku”, ale to było lata temu i najwyraźniej o tym zapomniałem. Byłoby miło, gdyby lspokazał ten bit, lub gdyby którekolwiek z pozostałych poleceń, których użyłem, zawierały bardziej pomocne (i konkretne) komunikaty o błędach dotyczące tego, dlaczego odmówiono uprawnień.

— Stephen Ostermiller,

Wszystko touchwie, że system nazwać próbę ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) nie powiodła się EACCESS. (Użyj, strace -efile touch apache.pemaby zobaczyć wywołania systemowe związane z plikami, które wykonuje). Jak mówi strona podręcznika dla tego wywołania systemowego , istnieje wiele możliwych przyczyn EACCESS, a wiele z nich dotyczy katalogów nadrzędnych, a nie samego pliku. Kod piśmie do dokładnie wydedukować dlaczego wywołanie systemowe zwrócił błąd to zrobił byłoby niezwykle trudne, ponieważ różne systemy plików i systemów operacyjnych są różne ...

— Peter Cordes

Tak czy inaczej, uniwersalna konwencja mówi, że gdy coś zawiedzie, sprawdzasz ciąg błędów dla kodu błędu ( errno) i drukujesz go. (Korzystanie ze standardowej perrorfunkcji biblioteki C lub równoważnej). Jest to jeden z rzadkich przypadków, w których nie zawsze jest to wystarczająca wskazówka dla użytkownika, aby szybko znaleźć problem, ale przez większość czasu działa bardzo dobrze. (Zwłaszcza w połączeniu z sytuacją, stracew której istnieją wątpliwości co do tego, która dokładnie operacja spowodowała błąd.) Nie jest idealny, ale może być znacznie gorzej (por. MS Windows, w którym co najwyżej dostajesz kod błędu do Google.)

— Peter Cordes

Po prostu zabawy z chattr +i, i zauważyłem, że rm foo(bez -f) komunikaty: rm: remove write-protected regular file ‘foo’. Ponieważ faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX rmdomyślnie wymaga monitowania przed usunięciem plików chronionych przed zapisem i dlatego sprawdza przede wszystkim. Tak więc szybciej dostałbyś dużą wskazówkę, gdybyś jej nie używał rm -f. : / access(3)prosi jądro o sprawdzenie uprawnień tak, jakby naprawdę otwierało się do zapisu, więc pobiera listy ACL i atrybuty.

— Peter Cordes,