Podsumowanie: nie „naprawiaj” głównych katalogów montowania w ZimaOS za pomocą chmod 777
W wersji 1.6.2 Beta 2 nowo zamontowane woluminy Btrfs pojawiały się jako root:root z uprawnieniami 755, więc zwykły użytkownik SSH nie mógł już bezpośrednio zapisywać w katalogu głównym /media/<volume>. Była to rzeczywista obserwacja z wersji beta. Nie oznacza to automatycznie, że bieżące wydanie jest uszkodzone, a rekurencyjne poluzowanie uprawnień głównego katalogu montowania jest ryzykownym obejściem.
Wersja beta zmieniła więcej niż jedną ścieżkę zabezpieczeń pamięci masowej
W powiązanym zgłoszeniu dotyczącym wersji 1.6.2 Beta 2 wykazano, że migracja danych aplikacji była blokowana przez nową politykę bezpieczeństwa, a IceWhale potwierdziło, że ta konkretna awaria migracji była znanym problemem, który miał zostać naprawiony. W późniejszej stabilnej wersji 1.6.2 wprowadzono szersze wzmocnienia zabezpieczeń i poprawki dotyczące pamięci masowej. Okres wersji beta obejmował więc zarówno celowe zmiany bezpieczeństwa, jak i co najmniej jedną regresję.
Podsumowanie zmian w ZimaOS 1.6.x stanowi przydatny kontekst historyczny.
Obecna dokumentacja publiczna nie obiecuje dostępu z zapisem bez uprawnień roota do każdego głównego katalogu montowania
ZimaOS traktuje obecnie pamięć masową jako zarządzaną usługę używaną przez aplikacje Pliki, udziały SMB i ścieżki Dockera. Obsługiwany sposób pracy polega na tworzeniu folderów i udziałów oraz mapowaniu aplikacji do właściwej ścieżki, a nie na poleganiu na dowolnych zapisach powłoki w katalogu głównym każdego zamontowanego dysku.
Aktualny przewodnik po pamięci masowej ZimaOS oraz przewodnik ZimaOS po ścieżkach aplikacji i migracji są obecnie lepszymi źródłami niż sam tryb systemu plików z wersji beta.
Jeśli skrypt wymaga dostępu z zapisem, przyznaj mu dedykowany katalog
sudo mkdir -p /media/YourVolume/automation
sudo chown YOUR_USER:YOUR_GROUP /media/YourVolume/automation
sudo chmod 775 /media/YourVolume/automationWskaż katalog, którego skrypt rzeczywiście potrzebuje. Nie zmieniaj rekurencyjnie całego głównego katalogu dysku. Podręcznik chmod i podręcznik chown to źródła nadrzędne.
Jak odróżnić politykę od regresji
Jeśli dostęp przez Pliki/SMB/aplikację działa, ale bezpośredni zapis z powłoki w głównym katalogu woluminu kończy się niepowodzeniem, może to być zgodne z modelem zarządzanych uprawnień. Jeśli obsługiwany interfejs Migracji danych lub udziałów jest zablokowany, zapisz dokładny komunikat błędu i wersję; jest to inna klasa problemu, którą należy sprawdzić w bieżącym stabilnym wydaniu.
