Czy dobrym pomysłem jest wywoływanie poleceń powłoki z poziomu C?

Istnieje polecenie powłoki unix ( udevadm info -q path -n /dev/ttyUSB2), które chcę wywołać z programu C. Mając zapewne około tydzień walki, mógłbym sam go wdrożyć, ale nie chcę tego robić.

Czy ogólnie przyjętą dobrą praktyką jest po prostu dzwonienie popen("my_command", "r");, czy też spowoduje to niedopuszczalne problemy z bezpieczeństwem i przekaże problemy ze zgodnością? Robienie czegoś takiego jest dla mnie złe, ale nie mogę wskazać, dlaczego byłoby to złe.

Nie jest to szczególnie złe, ale są pewne zastrzeżenia.

1. jak przenośne będzie twoje rozwiązanie? Czy wybrany plik binarny będzie wszędzie działał tak samo, generując wyniki w tym samym formacie itp.? Czy wyjdzie inaczej w ustawieniach LANGitp.?
2. ile dodatkowego obciążenia to dodaje do twojego procesu? Rozwidlenie pliku binarnego powoduje o wiele większe obciążenie i wymaga więcej zasobów niż wykonywanie wywołań bibliotecznych (ogólnie). Czy jest to dopuszczalne w twoim scenariuszu?
3. Czy są problemy z bezpieczeństwem? Czy ktoś może zastąpić twój wybrany plik binarny innym, a potem dokonać niegodziwych czynów? Czy używasz argumentów dostarczonych przez użytkownika do pliku binarnego i czy mogą one dostarczać ;rm -rf /(na przykład) (zwróć uwagę, że niektóre interfejsy API pozwalają na bezpieczniejsze określanie argumentów niż podawanie ich w wierszu poleceń)

Generalnie z przyjemnością wykonuję pliki binarne, gdy jestem w znanym środowisku, które mogę przewidzieć, kiedy dane binarne można łatwo przeanalizować (w razie potrzeby - może być potrzebny kod zakończenia) i nie muszę tego też robić często.

Jak już zauważyłeś, innym problemem jest to, ile pracy wymaga odtworzenie tego, co robi plik binarny? Czy korzysta z biblioteki, którą możesz wykorzystać?

Kiedy wprowadzasz potencjalny wektor, należy zachować szczególną ostrożność, aby uchronić się przed podatnością na wstrzyknięcia. To jest teraz w twojej głowie, ale później możesz potrzebować możliwości wyboru ttyUSB0-3, wtedy ta lista będzie używana w innych miejscach, więc zostanie uwzględniona zgodnie z zasadą jednej odpowiedzialności, a następnie klient będzie musiał wprowadzić dowolne urządzenie na liście, a programista dokonujący tej zmiany nie będzie miał pojęcia, że ​​lista ostatecznie zostanie użyta w niebezpieczny sposób.

Innymi słowy, kod jakby najbardziej nieostrożny programista, którego znasz, wprowadza niebezpieczną zmianę w pozornie niezwiązanej części kodu.

Po drugie, dane wyjściowe narzędzi CLI nie są ogólnie uważane za stabilne interfejsy, chyba że dokumentacja je specjalnie oznaczy. Być może możesz na nich liczyć, że uruchomisz skrypt, który możesz rozwiązać samodzielnie, ale nie na coś, co wdrożysz u klienta.

Po trzecie, jeśli chcesz w łatwy sposób wyodrębnić wartość ze swojego oprogramowania, istnieje szansa, że ​​ktoś też tego chce. Poszukaj biblioteki, która już robi to, co chcesz. libudevzostał już zainstalowany w moim systemie:

#include <libudev.h>
#include <sys/stat.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
    struct stat statbuf;

    if (stat("dev/ttyUSB2", &statbuf) < 0)
        return -1;
    struct udev* udev = udev_new();
    struct udev_device *dev = udev_device_new_from_devnum(udev, 'c', statbuf.st_rdev);

    printf("%s\n", udev_device_get_devpath(dev));

    udev_device_unref(dev);
    udev_unref(udev);
    return 0;
}

W tej bibliotece znajdują się inne przydatne funkcje. Domyślam się, że jeśli potrzebujesz tego, niektóre pokrewne funkcje również mogą się przydać.

W konkretnym przypadku, w którym chcesz się wywołać udevadm, podejrzewam, że możesz pobrać się udevjako biblioteka i wykonać odpowiednie wywołania funkcji jako alternatywę?

np. możesz rzucić okiem na to, co robi sam udevadm podczas wywoływania w trybie „informacji”: https://github.com/gentoo/eudev/blob/master/src/udev/udevadm-info.c i wykonywać połączenia equiv co do tych, które robi udevadm.

Pozwoliłoby to uniknąć wielu kompromisów wymienionych w doskonałej odpowiedzi Briana Agnewa - np. Nie polegając na pliku binarnym istniejącym na określonej ścieżce, unikając kosztów rozwidlenia itp.

Twoje pytanie wymagało leśnej odpowiedzi, a odpowiedzi tutaj wydają się podobne do drzew, więc pomyślałem, że dam ci leśną odpowiedź.

Bardzo rzadko pisane są programy C. Zawsze tak pisane są skrypty powłoki, a czasem pisane są programy Python, Perl lub Ruby.

Ludzie zwykle piszą w języku C, aby ułatwić korzystanie z bibliotek systemowych i bezpośredni dostęp do wywołań systemowych na niskim poziomie, a także szybkość. Język C jest trudny do napisania, więc jeśli ludzie nie potrzebują tych rzeczy, wówczas nie używają języka C. Oczekuje się również, że programy w języku C będą zależały tylko od bibliotek współdzielonych i plików konfiguracyjnych.

Ucieczka do podprocesu nie jest szczególnie szybka i nie wymaga drobnoziarnistego i kontrolowanego dostępu do obiektów systemowych niskiego poziomu, i wprowadza potencjalnie zaskakującą zależność od zewnętrznego pliku wykonywalnego, więc nie jest rzadkością w programach C.

Istnieją pewne dodatkowe obawy. Bezpieczeństwo i przenośność dotyczą osób, które wspominają, są całkowicie ważne. Oczywiście są one równie ważne dla skryptów powłoki, ale ludzie oczekują tego rodzaju problemów w skryptach powłoki. Jednak zwykle nie oczekuje się, że programy typu C będą miały tę klasę bezpieczeństwa, co czyni je bardziej niebezpiecznymi.

Ale moim zdaniem największe obawy dotyczą sposobu popeninterakcji z resztą twojego programu. popenmusi utworzyć proces potomny, odczytać jego dane wyjściowe i zebrać status wyjścia. W międzyczasie stderr tego procesu zostanie podłączony do tego samego stderr co twój program, co może powodować mylące wyjście, a jego stdin będzie taki sam jak twój program, co może powodować inne interesujące problemy. Możesz rozwiązać ten problem, dołączając </dev/null 2>/dev/nullciąg, który przekazujesz, popenponieważ jest on interpretowany przez powłokę.

I popentworzy proces potomny. Jeśli zrobisz coś z obsługą sygnałów lub rozwidlaniem procesów, możesz otrzymać dziwne SIGCHLDsygnały. Twoje wezwania do waitmogą dziwnie współdziałać popeni stwarzać dziwne warunki wyścigowe.

Istnieją oczywiście obawy dotyczące bezpieczeństwa i przenośności. Tak jak w przypadku skryptów powłoki lub czegokolwiek, co uruchamia inne pliki wykonywalne w systemie. I musisz uważać, aby ludzie używający twojego programu nie byli w stanie wprowadzić meta-znaków w powłoce do łańcucha, który przekazujesz, popenponieważ ten łańcuch jest przekazywany bezpośrednio za shpomocą sh -c <string from popen as a single argument>.

Ale nie sądzę, że są, dlaczego to jest dziwne, aby zobaczyć program C przy użyciu popen. To dziwne, ponieważ C jest zwykle językiem niskiego poziomu, a popennie niskim poziomem. A ponieważ użycie popenograniczeń projektowych ogranicza Twój program, ponieważ dziwnie współdziała ze standardowym wejściem i wyjściem Twojego programu i utrudnia zarządzanie procesami lub obsługę sygnałów. A ponieważ zwykle nie oczekuje się, że programy C będą miały zależności od zewnętrznych plików wykonywalnych.

Twój program może podlegać atakom hakerskim itp. Jednym ze sposobów ochrony przed tego rodzaju działaniami jest utworzenie kopii bieżącego środowiska komputera i uruchomienie programu przy użyciu systemu o nazwie chroot.

Z punktu widzenia twojego programu jego działanie odbywa się w normalnym środowisku, z punktu widzenia bezpieczeństwa, jeśli ktoś złamie twój program, ma on dostęp tylko do elementów, które podałeś podczas tworzenia kopii.

Taka konfiguracja nazywa się więzieniem chroot, aby uzyskać więcej informacji, zobacz więzienie chroot .

Zwykle służy do konfigurowania publicznie dostępnych serwerów itp.