Warum produziert Sysctl E_INVAL auf Mac OS X?

Question

Im Folgenden finden Sie eine abgespeckte (Fehler / Null-Kontrollen weggelassen) Schnipsel von C / Obj-C-Code, dass Anwendungen die argv eines bestimmten Prozess mit PID 50 erhalten sysctl.

...
int getProcessArgs[3] = { CTL_KERN, KERN_PROCARGS, 50 };
sysctl(getProcessArgs, 3, NULL, &length, NULL, 0);
char* processArgs = malloc(length * sizeof(char));
sysctl(getProcessArgs, 3, processArgs, &length, NULL, 0);
...

Der erste Aufruf von Sysctl (die Größe des argv String-Array zu bestimmen) erfolgreich ist. Die zurückgegebene Länge von ~ 1600, größer als ich erwarten würde, aber ich nehme nicht unvernünftig. Malloc erfolgreich ist. Der zweite Aufruf von sysctl -1 zurück, das Setzen von errno bis 22, E_INVAL.

Ich habe in anderen Code sah, einschließlich der von diese Frage , kann aber das Problem mit meinem nicht sehen. Was bin ich?

Answer 1

Ich habe versucht, den Code oben in ein Programm Einwickeln, und es funktioniert gut und druckt der andere Prozess des argv etc , wenn man über einen meiner eigenen Prozesse anfragende , das heißt mit der gleichen uid wie die Prozess rufenden sysctl().

Die „größer als ich erwarten würde“ Aspekt ist, dass die Umgebungsvariablen des Prozesses sowie die Befehlszeilenargumente zurückgegeben. (Es ist nicht klar, was das Format aller dieser Informationen ist.)

Bei Anfragen über ein andere Benutzer-Prozess, ich die gleiche EINVAL aus dem zweiten sysctl bekommen, dass Sie sehen, habe. Ich denke, das unvernünftig Neugier auf andere Menschen die Prozesse in Betracht gezogen wird, aber man würde denken, dass der erste sysctl wäre versagen.

(Wenn man über eine nicht vorhandene pid Anfragen, die erste sysctl nicht mit EINVAL.)

Das scheint alles massiv underdocumented werden. Auf Leopard, KERN_PROCARGS nicht erscheint auch in der sysctl Manpage