È una buona idea chiamare i comandi di shell da C?

C'è un comando shell unix ( udevadm info -q path -n /dev/ttyUSB2) che voglio chiamare da un programma C. Con probabilmente circa una settimana di lotta, potrei implementarlo di nuovo da solo, ma non voglio farlo.

È una buona pratica ampiamente accettata per me semplicemente chiamare popen("my_command", "r");o introdurrà problemi di sicurezza inaccettabili e inoltra problemi di compatibilità? Mi sembra sbagliato fare qualcosa del genere, ma non riesco a capire perché sarebbe male.

Non è particolarmente male, ma ci sono alcuni avvertimenti.

1. quanto sarà portatile la tua soluzione? Il tuo binario scelto funzionerà allo stesso modo ovunque, produrrà i risultati nello stesso formato ecc.? Produrrà in modo diverso sulle impostazioni di LANGecc.?
2. quanto carico aggiuntivo aggiunge questo al tuo processo? Il fork di un binario comporta un carico molto maggiore e richiede più risorse rispetto all'esecuzione di chiamate in libreria (in generale). È accettabile nel tuo scenario?
3. Ci sono problemi di sicurezza? Qualcuno può sostituire il binario che hai scelto con un altro, e compiere azioni nefaste in seguito? Usi arg forniti dall'utente per il tuo file binario e potrebbero fornirli ;rm -rf /(ad esempio) (nota che alcune API ti permetteranno di specificare gli arg in modo più sicuro che semplicemente fornirli dalla riga di comando)

Sono generalmente felice di eseguire i binari quando sono in un ambiente noto che posso prevedere, quando l'output binario è facile da analizzare (se necessario, potrebbe essere necessario solo un codice di uscita) e non ho bisogno di farlo anch'io spesso.

Come hai notato, l'altro problema è quanto lavoro è replicare quello che fa il binario? Utilizza una libreria che puoi anche sfruttare?

Ci vuole estrema cura contro le vulnerabilità dell'iniezione una volta introdotto un potenziale vettore. Ora è in prima linea nella tua mente, ma in seguito potresti aver bisogno della possibilità di selezionare ttyUSB0-3, quindi quell'elenco verrà utilizzato in altri luoghi in modo che venga preso in considerazione per seguire il principio della responsabilità singola, quindi un cliente avrà l'obbligo di mettere un dispositivo arbitrario nell'elenco e lo sviluppatore che apporta tale modifica non avrà idea che alla fine l'elenco verrà utilizzato in modo non sicuro.

In altre parole, codifica come se lo sviluppatore più negligente che conosci stia apportando una modifica non sicura in una parte apparentemente non correlata del codice.

In secondo luogo, l'output degli strumenti CLI non viene generalmente considerato come interfaccia stabile a meno che la documentazione non li contrassegni specificamente come tali. Potresti contare su di loro per uno script che esegui per risolvere te stesso, ma non per qualcosa che distribuisci a un cliente.

In terzo luogo, se vuoi un modo semplice per estrarre un valore dal tuo software, è probabile che anche qualcun altro lo desideri. Cerca una libreria che fa già quello che vuoi. libudevera già installato sul mio sistema:

#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;
}

C'è un'altra utile funzionalità in quella libreria. Immagino che se ne avessi bisogno, anche alcune delle funzioni correlate potrebbero tornare utili.

Nel tuo caso specifico, dove vuoi invocare udevadm, sospetto che potresti udeventrare in una libreria e fare le chiamate di funzione appropriate in alternativa?

ad esempio, potresti dare un'occhiata a cosa sta facendo udevadm quando invoca in modalità "info": https://github.com/gentoo/eudev/blob/master/src/udev/udevadm-info.c ed effettua chiamate equiv per quanto sta facendo udevadm.

Ciò eviterebbe la maggior parte dei compromessi negativi elencati nella risposta eccellente di Brian Agnew - ad esempio, non fare affidamento sul binario esistente in un determinato percorso, evitando le spese di fork, ecc.

La tua domanda sembrava richiedere una risposta da foresta, e le risposte qui sembrano risposte da albero, quindi ho pensato di darti una risposta da foresta.

Questo è molto raro il modo in cui sono scritti i programmi C. È sempre il modo in cui vengono scritti gli script di shell e talvolta il modo in cui vengono scritti i programmi Python, perl o Ruby.

Le persone in genere scrivono in C per un facile utilizzo delle librerie di sistema e un accesso diretto a basso livello alle chiamate di sistema del sistema operativo, nonché per la velocità. E C è un linguaggio difficile in cui scrivere, quindi se le persone non hanno bisogno di quelle cose, allora non usano C. Inoltre, ci si aspetta che i programmi C abbiano dipendenze solo su librerie condivise e file di configurazione.

Rivolgersi a un processo secondario non è particolarmente veloce e non richiede un accesso controllato e dettagliato a strutture di sistema di basso livello e introduce una dipendenza forse sorprendente da un eseguibile esterno, quindi è raro vedere nei programmi C.

Ci sono alcune preoccupazioni aggiuntive. La sicurezza e la portabilità riguardano le persone menzionate che sono completamente valide. Ovviamente sono ugualmente validi per gli script di shell, ma le persone si aspettano questo tipo di problemi negli script di shell. Ma in genere non ci si aspetta che i programmi C presentino questa classe di problemi di sicurezza, il che lo rende più pericoloso.

Ma, a mio avviso, le maggiori preoccupazioni riguardano il modo in popencui interagiranno con il resto del programma. popendeve creare un processo figlio, leggere il suo output e raccogliere il suo stato di uscita. Nel frattempo, quel processo 'stderr sarà collegato allo stesso stderr del tuo programma, il che potrebbe causare risultati confusi, e il suo stdin sarà lo stesso del tuo programma, che potrebbe causare altri problemi interessanti. Puoi risolverlo includendo </dev/null 2>/dev/nullla stringa che passi popenpoiché è interpretata dalla shell.

E popencrea un processo figlio. Se fai qualcosa con la gestione del segnale o i processi di fork, potresti finire per ricevere SIGCHLDsegnali strani . Le tue chiamate a waitpossono interagire stranamente con popene forse creare condizioni di gara strane.

I problemi di sicurezza e portabilità ci sono ovviamente. Come lo sono per gli script di shell o qualsiasi cosa che avvii altri eseguibili sul sistema. E devi stare attento che le persone che usano il tuo programma non sono in grado di inserire i meta-charcater della shell nella stringa in cui passi popenperché quella stringa viene fornita direttamente shcon sh -c <string from popen as a single argument>.

Ma non credo che siano il motivo per cui è strano vedere un programma C in uso popen. Il motivo per cui è strano è che C è in genere un linguaggio di basso livello e popennon è di basso livello. E perché l'uso di popenvincoli progettuali pone sul tuo programma perché interagirà stranamente con l'input e l'output standard del tuo programma e renderà difficile fare la tua gestione dei processi o la gestione del segnale. E poiché non ci si aspetta che i programmi C abbiano dipendenze da eseguibili esterni.

Il tuo programma potrebbe essere soggetto a pirateria informatica ecc. Un modo per proteggerti da questo tipo di attività è creare una copia del tuo ambiente macchina attuale ed eseguire il tuo programma usando un sistema chiamato chroot.

Dal punto di vista del programma si sta eseguendo in un ambiente normale, da un aspetto della sicurezza, se qualcuno rompe il programma ha accesso solo agli elementi forniti al momento della copia.

Tale configurazione è chiamata prigione chroot per maggiori dettagli, vedi prigione chroot .

Viene normalmente utilizzato per configurare server accessibili al pubblico, ecc.