[…] care to elaborate, […]
Ależ postaram się. W miarę możliwości, oczywiście, wszak ustalmy na wstępie pewne wyjściowe: moja wiedza na temat uniksowych podwalin macOS (i wcześniejszych) oraz operacji we wszelakich powłokach jest skromniejsza niż Twoja (forma porównania chyba zaczyna być symptomatyczna) i w momencie, kiedy Ty kończysz pisać onelinera, dajmy na to, ja dopiero zaczynam pierwsze akapity manuala – także tego…
Skoro to już mamy załatwione, kontynuujmy. Wiesz na pewno, bez krygowania się, co zawiera katalog /var -> /private/var w ogólności, w przypadku konkretnym /var/folders natomiast ładnie kwestię rozpisano tutaj: https://web.archive....ar-folders.html. Nasza rodaczka też precyzyjnie to wyłuszczyła w skądinąd interesującym artykule dotyczącym (nie)bezpieczeństwa powiadomień: https://kieczkowska....ions-forensics/. Listując sobie w długim formacie podkatalogi podkatalogów (ls -l /var/folders/*) można zobaczyć po username, czyje dokładnie dane są w środku każdego z dwuznakowo nazwanych.
Przejdźmy do niniejszego problemu. Wynikało z oryginalnego opisu, że nsurlsessiond zapętlił się z „czymśtam” na bardziej niż rozsądny czas. Z tego, co kiedyś wyczytałem w sieci (tu, niestety, źródeł nie pomnę, ale pewnie da się znaleźć), procesowi temu głównie chodzi o synchronizację między chmurą a urządzeniem końcowym wszelakich danych iCloudowych, z czego większość kontroluje on „pod rządami” naszego usera. Są jednak wyjątki, nie tylko dla nsurlsessiond, zarządzane – prawdopodobnie ze względów bezpieczeństwa – poza nazwą $USER, w zamian stoi za nimi username identyczny z nazwą procesu (albo też root). Apple z oczywistych względów nie udostępnia na ten temat dokładnej dokumentacji, toteż źródła są niesolidne i spekuluję w tym miejscu, lecz jako że nie zamierzam, bazując na tych przypuszczeniach, wykonywać żadnych podejrzanych operacji, pozwolę sobie na hitchcockowskie zawieszenie niewiary. No i te „nie nasze”, nie fizycznego usera caches, databases etc., potrzebne szeroko pojętemu systemowi, są zapisywane właśnie w /var/folders/zz/<random>, co widać po powyższym listowaniu, jak też wnioskować można po ich ochronie – flaga sunlnk, atrybut rozszerzony com.apple.rootless. Dlatego też na nich skupiło się poszukiwanie.
Po zapisach w Konsoli widać, że tematowy proces nie może tamże stworzyć podkatalogu /var/folders/zz/*/0/, bo mu się uprawnienia nie zgadzają i tak próbuje w kółko. Nie wiem, czy sama zabawa ze zmienianiem uprawnień pomogłaby (wiem, że są podzielone zdania na temat zasadności ich naprawiania ;-)) , ale na pewno skasowanie katalogu pozwoli procesowi powiązanemu odbudować całą ścieżkę i stworzyć wreszcie wymagany przez niego podkatalog.
Dlaczego zamieszałem w to trustd, pozornie niezwiązany? Pewnie w tym tutaj wypadku nawet nie trzeba było go tłuc (nic nie widać przynajmniej w linku z wynikami z Konsoli od OP, może nie korzysta z pęku kluczy w iCloud?), tym niemniej w zapisach innych osób z tym problemem przeczytałem oraz u siebie kiedyś doświadczyłem, że trustd (z definicji uprawomocniający wszelakie certyfikaty) stawał się wówczas quasi-parentem nad nsurlsessiond czy też jego „współpracownikiem” (być może tylko dla weryfikacji, czy jakieś certyfikaty nie idą do iCloud Keychain? ponownie: nie wiem, nie ma dokumentacji, podejrzewam sobie w cichości ducha; osobiście nie mam żadnych certyfikatów w pęku chmurowym, przed chwilą zerknąłem, bazuję na informacjach z drugiej ręki) i samo zabicie ostatniego nie wystarczało, bo trustd zwieszał się wraz z nim na nieudanym zapisie. Gruntowniejsza analiza wymagałaby większej ilości przypadków.
Póki co, wolałem chuchnąć na zimne i doradzić zabicie także tego, który wzbudzał podejrzenia bycia nadrzędnym, na czas wystarczający do usunięcia katalogu cache'ów, po zniknięciu którego procesy zrestartowały, odbudowały, co trzeba, z odpowiednimi już przywilejami, atrybutami, flagami itd. (chodziło głównie o xattr dla tego sub-, należącego do _nsurlsessiond w katalogu zz, czyli hic: zyxvpxvq6csfxvn_n00000y800007k), zapisały sobie wewnątrz inkryminowanego raz a dobrze, już bez wpadania w loop – et voilà!
Jak na początku wspomniałem: moja znajomość tematu jest bardziej hobbystyczna (choć niekiedy skuteczna) niż profesjonalna, więc również jakbyś chciał podeprzeć swoją zawodową, go ahead!
I ja pogłębię. ;-)
Dzięki z wyprzedzeniem.
Screenshot 2020-06-02 at 11.03.01.jpg 126,46 KB
2 Ilość pobrań
