Jak nieinwazyjnie przetestować dostęp do zapisu w pliku?

W jaki sposób w skrypcie powłoki mogę w łatwy i nieinwazyjny sposób sprawdzać dostęp do zapisu do pliku bez faktycznej próby modyfikacji pliku?

Mógłbym przeanalizować dane wyjściowe stat, ale wydaje się to naprawdę skomplikowane i być może kruche, chociaż nie jestem pewien, jak wiele danych statystycznych różni się w zależności od implementacji i czasu.

Mógłbym dołączyć na końcu pliku i sprawdzić, czy to się powiedzie, ale to potencjalnie niebezpieczne, z dwóch powodów, o których mogę myśleć:

1. Teraz muszę usunąć dodatek, a jeśli jakiś inny proces zapisuje do pliku, to natychmiast staje się nietrywialne, ponieważ moja linia nie jest już ostatnią.
2. Każdy proces odczytywający plik może mieć dowolne wymagania dotyczące zawartości tego pliku, a ja właśnie mogłem zepsuć tę aplikację.

Wystarczy użyć wflagi - testużyteczności:

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

Pamiętaj, że jeśli zamierzasz później zapisać plik, nadal możliwe jest, że nie będziesz mógł do niego zapisać. Plik mógł zostać przeniesiony, uprawnienia mogły ulec zmianie itp. Może się również zdarzyć, że -wwykryje uprawnienia do zapisu, ale interweniuje jakiś inny czynnik, aby uniemożliwić zapisywanie pliku .

Inne podejście:

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

Spowoduje to próbę otwarcia pliku w celu dołączenia, a jeśli to się powiedzie, nie uruchom żadnej komendy (tj. Uruchom komendę zerową ) z wyjściem do pliku. 

Uważaj, aby utworzyć pusty plik, jeśli nie istniał.

-wOperator testpolecenia może po prostu zrobić stat , a następnie spróbuj dowiedzieć się, czy wygląda na to trzeba mieć dostęp. Moja alternatywa (powyżej) jest bardziej niezawodna niż testpodejście w niektórych specjalnych warunkach, ponieważ wymusza sprawdzenie dostępu przez jądro, a nie powłokę. Na przykład,

• jeśli plik znajduje się w systemie plików innym niż Unix - zwłaszcza jeśli jest on zdalnie zamontowany z serwera plików innego niż Unix - ponieważ statmoże zwrócić mylącą wartość trybu.
• jeśli plik znajduje się w systemie plików, który jest zamontowany tylko do odczytu.
• jeśli plik ma ACL, a tryb sprawia, że ​​wygląda na to, że powinieneś mieć dostęp, ale ACL go zaprzecza lub odwrotnie.
• jeśli niektóre ramy bezpieczeństwa (AppArmor, SELinux,…) odmawiają dostępu do pliku.

G-man ma rację: [ -w ]nie zawsze mówi prawdę. Tutaj, aby poradzić sobie z nieistniejącym plikiem i wiadomością odmowy uprawnień z powłoki:

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

Aktualizacja : Wygląda przerażająco, prawda? No cóż, tak jest. Hmm ... jak to sformułować ... NIE UŻYWAJ TEGO, chyba że doskonale wiesz, że jesteś w warunkach, w których wymaga on działania zgodnie z oczekiwaniami. Zobacz komentarz Stephane'a.

Co zatem wyciągnąć wniosek? Nawet jeśli [ -w ]nie mówi prawdy, jest to jedno polecenie, które ma wykonać zadanie. Jeśli tak się nie stanie, będziemy go winić, pisać raporty o błędach i będzie działać w przyszłości. Lepiej sprawdź warunki, w jakich działa i używa [ -w ]; napisz specjalny kod dla specjalnych przypadków. Obejścia mają swoje własne warunki.

[ -w /path/to/file ]

jest najlepszy a priori .