Почему sysctl создает E_INVAL в Mac OS X?

Question

Ниже приведен фрагмент кода C / Obj-C, который использует sysctl для получения argv определенного процесса с PID 50.

...
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);
...

Первый вызов sysctl (для определения размера строкового массива argv) завершается успешно. Возвращенная длина ~ 1600, больше, чем я ожидал, но я полагаю, что это необоснованно. Маллок добивается успеха. Второй вызов sysctl возвращает -1, устанавливая errno равным 22, E_INVAL.

Я посмотрел другой код, в том числе из этот вопрос , но не вижу проблемы с моим. Чего мне не хватает?

Answer 1

Я попытался обернуть ваш код в программу, и он работает нормально и печатает argv и т. Д. Другого процесса при запросе об одном из моих собственных процессов , т. Е. С тем же uid, что и у процесса вызывая sysctl().

Аспект «больше, чем я ожидал» связан с тем, что возвращаются переменные среды процесса, а также аргументы командной строки. (Неясно, каков формат всей этой информации.)

При запросе о другом пользовательском процессе я получаю тот же EINVAL со второго sysctl, который вы видели. Я думаю, это считается необоснованным любопытством к процессам других людей, но вы думаете, что первый sysctl тоже потерпит неудачу.

(При запросе несуществующего pid первый sysctl завершается неудачно с EINVAL.)

Похоже, что все это недооценено: на Leopard KERN_PROCARGS даже не появляется на справочной странице sysctl.