Что должен делать антивирус, когда у него нет доступа к чтению/записи в определённом каталоге?

Если предполагается, что crawler должен обойти всё дерево, то само собой у него должны быть RO-права доступа. Через выделенную учетную запись, suid бит или иные способы (если они предусмотрены ОС)

Выдать себе права на запись и пробежаться по ней? Опасно.

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

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

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

Что ты несёшь? Какое ещё «выдать права»? Ты виндузятник?

Права либо есть либо нет, и это определяется uid:gid процесса. Антивирусы обычно работают от рута, соответственно все права у них есть.

А как быть тогда?

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

несмотря на странность постановки вопроса ТСа, тут ты не прав. есть вещи, которые от рута не читаются. простой пример: смонтированные юзером шифрованные каталоги (например, encfs). хоть ты рут, хоть сам Ктулху, ну нет у тебя прав на чтение. и в принципе это правильно. рут занимается административными делами, а безопасность - это вопрос доступа только конкретного пользователя.

А да, fusefs (encfs через неё работает) дефолтно недоступна никому кроме смонтировавшего её юзера, забыл про это. Но это вроде единственное исключение и fuse это не совсем обычная файловая система, по сути это ядерное посредничество для файлосистемной абстракции над пользовательскими структурами данных.

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

если какой-то зловред захватил сервер и получил рутовые права, он не получит шифрованные данные юзера. и это правильно.

Нет, тут дело совсем не в безопасности. Админ, разумеется, может без проблем прочитать подобные fuse (просто перелогинившись временно за того юзера, а в линуксе скорее всего даже проще можно с setfsuid()), или сдампить память процесса, его обслуживающего. Дело скорее именно в том, что подобные файловые системы - лишь абстракция над внутренним апи юзерского софта (вместо fuse могли бы быть какие-нить сокеты с собственным протоколом чтения/записи объектов), и незачем беспокоить рута их содержимым.

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

я не думала специально про защиту от рута. кроме TPM не могу ничего предположить с ходу. но, вероятно, если подумать, то можно придумать реализации.

Если он не смонтирован, то вопросов доступа к файлам и не возникнет - их просто не будет.

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

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

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

Где «тут»? Я в целом писал. fuse весьма либеральна в плане того, что именно она может показывать в виде файловой системы, и может нарушать ряд порядков, которые заведемы во всех настоящих фс.

это просто система организации работы с некими объектами, содержащими данные

Вот именно, а объекты могут быть какими угодно и не всегда ровно ложиться на абстракцию файловой системы, но fuse это позволяет. И вот чтобы всякое не пойми что не показывать тем, кому оно скорее всего не нужно, use дефолтно и прячет своё содержимое от остальных юзеров, включая рута. Но, повторю, это ни в коем случае не защита, а именно спрятывание всякой неудобной ерунды из публичного пространства. Рут при желании легко притворится в нужного юзера и эту проверку обойдёт.

дело в интерфейсе. ФС - это про интерфейс. у тебя есть проблемы работы с fuse? весь софт с ним нормально работает. потому что предоставлен стандартный интерфейс и ничего нигде не нарушается. какие-то личные тараканы и внутреннее представление данных (они вообще могут быть виртуальными) тут ни при чём.

например, те же devfs, sysfs - это вообще даже не физические объекты где-то на винте, это представление данных ядра в виде ФС через некоторые интерфейсы. что не мешает им быть вполне валидными ФС. софт обращается к ним по интерфейсам ФС и всё нормально работает.

Я не говорю что что-то прямо сразу сломается, но стандартные штуки работы с фс могут быть неуместны в случае fuse. В fuse может быть бесконечное количество файлов, в которых навсегда заблудится какой-нить индексатор, или неадекватный размер блока, который где-нить что-нить да сломает.

devfs и sysfs монтируются рутом в известных заранее местах, и разрабатываются авторами ядра - то есть там всё предусмотрено. А что будет в рандомном не пойми кем сделанном fuse - заранее неизвестно. Поэтому по умолчанию, чтобы никому не мешать, он монтируется в приватном режиме. Этот режим можно и отключить, если юзеру понадобилось, но это штука которую уже сознательно включают, задумываясь о том, а нужно ли это всё в общем файловом дереве.

Повторюсь ещё раз, это не какое-то жёсткое требование, это просто настройка «не мусорить в публичное пространство по-умолчанию».

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

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

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

Антивирус должен делать так как делает доктор веб в твоём примере - получать доступ обходя запреты