Jeśli utworzę plik jako użytkownik nieuprzywilejowany i zmienię tryb uprawnień na 400
, ten użytkownik zobaczy go jako tylko do odczytu, poprawnie:
$ touch somefile
$ chmod 400 somefile
$ [ -w somefile ] && echo rw || echo ro
ro
Wszystko dobrze.
Ale potem pojawia się root:
# [ -w somefile ] && echo rw || echo ro
rw
Co za cholera? Jasne, root może zapisywać do plików tylko do odczytu, ale nie powinien mieć z tego zwyczaju: najlepsza praktyka dyktuje, że powinienem być w stanie przetestować bit uprawnień do zapisu, a jeśli nie, to został ustawiony w ten sposób z jakiegoś powodu.
Chyba chcę zrozumieć, dlaczego tak się dzieje, i jak mogę uzyskać fałszywy kod powrotu podczas testowania pliku, w którym nie ma ustawionego bitu zapisu?
permissions
test
readonly
Bogaty
źródło
źródło
4.1.2(1)-release
), jak i RHEL7 (4.2.46(2)-release
)./etc/dhcp/dhcpd.conf
, której właścicielem jest root. Korzystam z dostarczonego przez dostawcędhcpd
. Totalna katastrofa, co? Plik jest sprawdzany w RCS, automatyzuję korzystaniercsdiff
,ci
aco
ponieważ mamy operatorów, którzy muszą ... operować. Kontrola bitów uprawnień (-w
jak szczegółowo opisanotest(1)
) miała być pierwszą linią awarii, działającą na podstawie, któraci -u
pozostawia plik tylko do odczytu. Porzucam to, idę prostorcsdiff -q
i sprawdzam$?
. Niesmacznydhcpd
? Byłby własnościądhcpd
.bash
itest
doprowadziły mnie do przekonania, że po to[ -w
jest.Odpowiedzi:
test -w
aka[ -w
nie sprawdza trybu plików. Sprawdza, czy można to zapisać. Tak jest w przypadku rootowania.Metodą, którą bym przetestował, byłoby porównanie bitowe z danymi wyjściowymi
stat(1)
(„%a
Prawa dostępu ósemkowe”).Uwaga: podpowłoka
$(...)
wymaga0
prefiksu, aby wynikstat
interpretowany był jako ósemkowy przez(( ... ))
.źródło
(( ... & ... ))
. Jedna literówka poprawiona :-)if
wymagane, dane wyjściowe uprawnień ósemkowych%a
nie są%d
i(( ... ))
wymaga prefiksu,0
aby interpretować dane wyjściowestat
jako ósemkowe.man stat
mówi „% d numer urządzenia dziesiętnie”, ale to, czego chcemy, to „prawa dostępu”, prawda? Twoja uwaga o potrzebie prefiksu 0 jest dobrze wykonana, ale myślę, że musimy po prostu go tam znaleźć :).stat -c 0%a
...Myślę, że źle zrozumiałeś
-w
. Nie sprawdza, czy plik ma „Uprawnienia do zapisu”, sprawdza, czy plik może zostać zapisany przez wywołującego użytkownika.Mówiąc dokładniej, wzywa
access(2)
lub podobnie.np. jeśli skrypt ma,
if [ -w /etc/shadow ]
to jeśli uruchomiszstrace
skrypt, możesz zobaczyć linię podobną doPonieważ
root
może zapisać do pliku, zwraca 0.np. jako zwykły użytkownik:
Jako root
To pomimo faktu, że
/etc/shadow
ma pozwolenie000
na moją maszynę.Teraz to, co chcesz robić, staje się interesujące i nie jest takie proste.
Jeśli chcesz sprawdzić proste uprawnienia, sprawdź dane
ls
wyjściowe, wywołaniestat
lub podobne. Pamiętaj jednak, że listy ACL mogą przekraczać te uprawnienia. Tylko dlatego, że plik ma uprawnienia 400, nie powstrzymuje go przed zapisywaniem ...źródło
-w
:test(1)
jest jawne: „PLIK istnieje i udzielono zezwolenia na zapis ”, a nie „ plik może zostać zapisany przez bieżącego użytkownika ”. Nic o nadpisywaniu uprawnień ani list ACL.bash(1)
to cagey: „Prawda, jeśli plik istnieje i można go zapisać ”.ksh(1)
robi subtelną wskazówkę w stosunku do shenanigans: „-w plik // Prawda, jeśli plik istnieje i można go zapisać w bieżącym procesie ”.zsh(1)
odsyła dotest(1)
,zshmisc(1)
jest sformułowane jakoksh(1)
izshexpn(1)
opisuje niektóre interesujące globowania oparte na uprawnieniach.csh(1)
jest przezabawnie zwięzły: „Dostęp do zapisu”.Użytkownik root może robić, co chce, „normalne” uprawnienia do plików nie stanowią ograniczenia. Nie wykona bezpośrednio zwykłego pliku bez żadnych uprawnień eXecute, tylko dla odrobiny ubezpieczenia przed ćwiczeniem nożnym.
źródło