sudo chown kończy się niepowodzeniem, a operacja jest niedozwolona

Znalazłem tutaj podobne pytania, ale odpowiedzi udzielone na te pytania nie rozwiązują mojego problemu.

Jeśli zrobię:

sudo chown <username> main.m

Otrzymuję błąd operacji niedozwolony.

Ogólnym rozwiązaniem wcześniejszych błędów było:

sudo chflags nouchg main.m

usunąć flagę blokady. Jednak po wykonaniu tej czynności nadal nie mogę zmienić pliku. Próbowałem też:

chflags noschg main.m

w trybie pojedynczego użytkownika bez powodzenia - dostaję błąd operacji niedozwolony.

Gdyby ktoś miał jakieś myśli, byłbym zainteresowany.

— ericg
źródło

Jaka jest podstawowa rzecz, którą próbujesz zrobić? Być może istnieje powód, dla którego plik ma blokadę.

— Tamara Wijsman

Mogę więc używać go jako danych testowych bez umieszczania kodu w bezpiecznym narzędziu pomocniczym, co wymaga dodatkowej pracy do debugowania - nie jest to niemożliwe, ale wystarczająco denerwujące, że jeśli mogę zmienić atrybuty pliku, więc bezpieczne narzędzie pomocnicze nie jest konieczne, to by trochę ułatwiło. Biorąc pod uwagę, że są to tylko dane testowe, które zostały utworzone, nie ma już żadnego dobrego powodu, aby mieć blokadę.

— ericg

Na jakim systemie plików znajduje się plik? Nie próbujesz używać chownsystemu plików NTFS / FAT, prawda?

— Zoredache,

@ericgorr: Większość tego jest ponad moją głową; Nie wiem, czym dokładnie jest bezpieczne narzędzie pomocnicze. Ale jak mówisz, to tylko utworzone dane testowe; czy poprawnie zamknąłeś plik testowy w kodzie?

— Tamara Wijsman

@Tom narzędzie pomocnicze jest sposobem OS X na nadanie aplikacji podwyższonych uprawnień przy jednoczesnym zachowaniu uprawnień - więc jeśli na przykład aplikacja chce zmodyfikować bezpieczny plik, informuje (autoryzowane) narzędzie pomocnicze o zmodyfikowaniu pliku. Zgaduję, że ericgorr chce uniknąć podniesienia swojej aplikacji lub czegoś w celu uniknięcia rygorystycznego debugowania, które się z tym wiąże.

— Verident

Pliki Mac można chronić na ~~cztery~~ trzy różne sposoby, o których wiem:

Standardowe prawa własności i uprawnienia Uniksa, takie jak r / w / x dla użytkownika / grupy / innych, które widzisz ls -li naprawiasz za pomocą chown(1)i chmod(1).
Flagi plików jak uchgi schgktóre widzisz ls -lOi naprawiasz za pomocą chflags(1).
Stare metadane Findera „Bit blokady”, które widzisz GetFileInfo filename. Możesz także zobaczyć obecność metadanych Findera, ale nie jego znaczenie, za pomocą ls -l@. Możesz to naprawić za pomocą SetFile(1). Nieważne, teraz jest to mapowane na uchgflagę.
Listy kontroli dostępu (ACL), które widzisz ls -lei naprawiasz za pomocą argumentów związanych z ACL do chmod(1).

Zobaczmy więc, co słychać w twoim pliku, łącząc wszystkie te flagi, aby ls:

ls -lO@e main.m

Wygląda na to, że już wiesz, jak radzić sobie z numerami 1 i 2.

Jeśli zobaczysz listę ACL (# 4), możesz to naprawić za pomocą argumentów związanych z listą ACL do chmod(1).

Jeśli nadal jesteś zakłopotany, zaktualizuj swoją odpowiedź o dane wyjściowe z tego połączonego lspolecenia, które zasugerowałem powyżej, abyśmy mogli zobaczyć, co się dzieje.

— Spiff
źródło

Wydaje się, że problem dotyczy list ACL. Interesujące jest dla mnie to, że sudo nie omija takich zamków. Ponadto chmod -R -a # 0 * usunął listy ACL z większości plików w hierarchii, ale nie usunął ich z niektórych - użycie sudo z chmod nie pomogło.

— ericg