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

Question

Вопрос:

Обратите внимание, что для целей данного вопроса я буду считать, что каталог представляет собой особый тип файла.

Кроме того, я буду предполагать (и, пожалуйста, исправьте меня, если я ошибаюсь), что права на запись в каталог включают право создавать новые файлы в указанной директории.

std::filesystem::perms перечислены следующие виды разрешения, каждый для трех типов операций read, write и execute:

• owner: Владелец файла.
• group: Группа пользователей файла.
• others: Все? (Не совсем уверен в этом, пожалуйста, исправьте, если ошибаетесь.)

Теперь, как легко видеть, если вы хотите знать, имеет ли выполняемая программа заданное право, эта информация является нетривиальной для получения от них:

• Является ли пользователь программы пользователем пользователя?
• Является ли какая-либо из группы пользователей файла одной или из группы пользователей программы?

Интересно, как представляется, не существует какой-либо функции в библиотеке, которая будет соответствовать следующей декларации функции:

enum FileAction { READ = 1, WRITE = 2, RW = READ|WRITE }; 

bool canDo(const std::filesystem::path & path, FileAction action); 

Как такая функция может быть реализована тогда?

Конечно, старый добрый pre-C++ 17 способ просто попытаться начать чтение/запись и поймать исключение, если он не сработает. Хотелось бы подумать, что библиотека Filesystem предложит более элегантное решение.

Меня интересуют ответы, применимые к Windows (XP +) и Linux. Пожалуйста, отметьте, если ваш ответ применим только к одному (даже если нужно надеяться, что универсальный ответ существует и может быть найден).

---

использования: (запозданием добавил, чтобы предотвратить против «вы не должны спросить это» ответы.)

констатируют в начале Игру ли его собственный каталог находится в допустимом состоянии: В конце концов, не нужно бежать, если он все равно потерпит неудачу.

We может предположить, что никакая другая программа не испортит каталог установки приложения.Если мы не можем, то у пользователя и их системы есть больше проблем, чем у сбойная игра и нам все равно.

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

До тех пор, как мы по-прежнему заботиться, мы хотим, чтобы обеспечить лучшее усилием аки жадного алгоритм аки догадку, можем ли мы ожидать, чтобы успешно работать.

Пользователь может быть непрофессиональным в работе с их операционной системой, а требует подсказок для обеспечения рабочей среды. Мы хотим предоставить все подсказки, которые мы можем, и только тогда прекратите заботу, потому что мы - приложение, а не ОС и, конечно, не системный администратор.

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

Это хорошо зарекомендовавшая себя практика для игр, чтобы эвристически проверить их каталог установки на предмет целостности. Steam предлагает это как сервис для всех игр, установленных через него. Star Trek Online, League of Legends, Warframe имеют пусковые установки, которые делают то же самое.

Эти игры обычно проверяют целостность файла, вычисляя (через чтение) хэши их файлов и сравнивая их с известными действительными хэшами.

Игра, в которой почти все файлы предназначены для модификации пользователем, такие как Крепость Гномов, не могут этого сделать. Это может, однако проверьте наличие прав на файлы, которые необходимо прочитать, и для записи прав на файлы, которые должны быть записаны. Опять же: нет цель в манипулировании такими правами во время игры, и поэтому его не следует предполагать.

Answer 1

«Просто попробуйте ввод/вывод и обработку сбоев» до сих пор является лучшим подход, по нескольким причинам (примерно в порядке убывания скорости вы будете запускать в них в реальном мире):

1. Предсказание сбоя требует воспроизведения всей логики управления доступом ОС, что вполне может быть зависящим от версии. Не изобретайте велосипед.

2. Предсказание сбоя, даже если сделано совершенно точно, сообщает вам только , а не то, что произойдет, когда операция ввода-вывода будет предпринята.Файловая система - это общий ресурс, и разрешения могут меняться. Это состояние гонки настолько распространено, что оно имеет свое собственное имя: TOCTOU (время проверки - время использования)

3. I/O все еще может выйти из-за множества других причин, не связанных с разрешением (диск был отключен пользователем , сеть опустилась, другой процесс исчерпал все свободное пространство).

В конечном счете вы не можете избежать обработки отказа, а выполнение как обработки разрешений, так и сбоев - это сложность без каких-либо преимуществ.

Я не знаю, почему вы добавили исключения в микс - просто откройте файл обычным способом (либо fstream, либо fopen) и проверьте результат. fstream дал бы объект с failbit set, fopen дал бы NULL, и в обоих случаях errno может помочь в диагностике причины.

Answer 2

Конечно, старый добрый пред-C++ 17 способом было бы просто попробовать и начать чтение/запись и поймать исключение, если это не удается. Я хотел бы подумать, что библиотека Filesystem предложит более элегантное решение .

Нет «более элегантного решения».

Любое такое предполагаемое «решение» было бы восприимчивым к TOCTOU race condition.

Вы не можете надежно проверить разрешение X, а затем попытаться выполнить X в отдельной операции.