Блог

Главная - Вопросы по программированию - Как моя программа на C может проверить, есть ли у нее разрешение на выполнение для данного файла?

Как моя программа на C может проверить, есть ли у нее разрешение на выполнение для данного файла?

#c #linux #permissions #execution

#c #linux #разрешения #выполнение

Вопрос:

Есть ли способ определить, может ли процесс выполнить файл без необходимости его фактического выполнения (например, путем вызова execv(filepath, args) только для сбоя и обнаружения этого errno == EACCES )?

Я мог бы stat открыть файл и наблюдать st_mode , но тогда я все еще не знаю, как это относится к процессу.

В идеале я ищу функцию, подобную

 get_me_permissions(filepath, amp;status); // me: the process calling this function
// when decoded, status tells if the process can read, write, and/or execute 
// the file given by filepath.

Заранее спасибо.

Комментарии:

1. Вы говорите о Windows, Linux или Mac?

2. @Nick: Linux — проверьте теги 🙂

3. Обратите внимание, что какой бы метод вы ни использовали, помните о потенциальной опасности гонки. Если что-то другое изменит права доступа к файлам после того, как вы их проверите, и до того, как вы попытаетесь выполнить файл, у вас возникнут проблемы!

4. @Oli: обычно это решается путем обеспечения достаточно длительного периода между ними, чтобы гонка казалась «естественной». Например, если вы хотите составить список всех исполняемых файлов, то вы используете права доступа к файлам — они могли измениться к тому времени, когда кто-то обработает информацию, и это ожидаемо. Если вы планируете выполнить его немедленно, то обычно нет смысла проверять, просто сделайте это…

Ответ №1:

Предполагая, что ваша конечная цель — в конечном итоге выполнить программу, вы этого не делаете. Этот тест был бы бесполезен, потому что результат потенциально неверен еще до того, как функция для выполнения проверки вернет! Вы должны быть готовы к сбою execve из-за ошибок разрешения.

Как указал Стив Джессоп, проверка того, является ли данный файл исполняемым, может быть полезной в некоторых ситуациях, таких как список файлов ( ls -l ) или визуальный файловый менеджер. Конечно, можно было бы придумать более эзотерическое применение, такое как использование битов разрешений файла для межпроцессного взаимодействия (интересно как метод, который не требует выделения каких-либо ресурсов), но я подозреваю, что более интересным вопросом будет stat («На какие биты разрешений установлены?»), а не access («Имеет ли вызывающий процесс разрешение X?»)…

Комментарии:

1. То же самое можно сказать о ls файлах, которые она перечисляет, возможно, исчезли или изменились к моменту вывода их имен в стандартный вывод. Конечно, нужно быть осторожным с этой проблемой при использовании, ls тем не менее ls это не «бесполезно».

2. @mark4o: В статье Википедии, на которую вы ссылались, похоже, содержится некоторая вводящая в заблуждение информация в разделе «предотвращение», но я не чувствую себя достаточно беспристрастным, чтобы исправить это. В частности, она отправляет исключения в качестве решения, когда любое средство попытки выполнения операции и проверки на сбой работает просто отлично, а что касается результата невозможности, то из этого не следует, что этот результат относится исключительно к access и аналогичным методам проверки и использования развязки, и что результат невозможности не влияет на вышеупомянутое решение.

Ответ №2:

http://linux.die.net/man/2/access

Обратите внимание на небольшую сложность, связанную с suid — если процесс обладает эффективными правами суперпользователя, это не принимается во внимание, поскольку общая идея функции заключается в проверке, должен ли исходный вызывающий пользователь иметь доступ к файлу, а не проверять, мог ли этот процесс получить доступ к файлу.

Комментарии:

1. В частности, используйте X_OK режим.

2. Голос отклонен, потому что важно, чтобы ответ @R .. выделялся.

3. @Matt: если вы так думаете, но ответ R .. содержит два неверных утверждения, за которыми следует предположение о коде спрашивающего (а именно о том, что спрашивающий планирует фактически выполнить что-либо), что уже адекватно описано в комментарии Oli к вопросу. Конечно, есть очевидный способ неправильного использования access , но было бы абсолютно неверно говорить, что никогда не полезно смотреть на текущие разрешения. Если я пишу файловый менеджер и хочу выделить программы, исполняемые текущим пользователем, я должен запускать каждый файл и проверять наличие ошибок? Я так не думаю.

4. Спасибо за ваши комментарии, ребята. access это именно то, что мне нужно, хотя я планирую обрабатывать ошибки там, где я собираюсь вызвать execve .