Можно ли сделать доступным ввод-вывод файла только для текущего процесса?

Речь о конкретном файле или I/O как таковом?

fcntl?

На самом деле нельзя, но можно сделать вид :)

Да. open(), а потом unlink(). Тогда те, кто файл не успел открыть, уже не откроют (без хаков).

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

Конкретный файл.

Озвучь уже, чего на самом деле хочешь добиться.

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

эм.. пишет туда/сюда в файл?! меня это смущает… но можно и так если осторожно, а что shm не подходит? там и права выставляются… а в unix сокетах можно вообще асинхронно + tls1.2 внутри поднять :D

Тогда те, кто файл не успел открыть, уже не откроют (без хаков).

Это само по себе хак и в общем случае не работает.

shm ... unix сокетах

shm или unix сокеты можно открыть как файл с произвольным доступом (в файловой системе)?

https://www.kernel.org/doc/html/v5.8/filesystems/mandatory-locking.html

Это не оно? Если кратко, то man fcntl не рекомендует ей пользоваться.

Mandatory locking

The Linux implementation of mandatory locking is subject to race conditions which render it unreliable: a write(2) call that overlaps with a lock may modify data after the mandatory lock is acquired; a read(2) call that overlaps with a lock may detect changes to data that were made only after a write lock was acquired. Similar races exist between mandatory locks and mmap(2). It is therefore inadvisable to rely on mandatory locking.

А тут ничего не работает. Как-то раз была модной идея сделать транзакции в ФС, но в итоге оказалось, что это тоже так себе. Единственная система, где они появились, это венда с ntfs, и то их оттуда убрали.

конечно можно, shm это кусок памяти между процессами

Как это сделать?

Не оно. В el9 и в 5.14 mandatory locking больше нет.

чисто теоретически загрузить туда свой файл :D да и какие проблемы организовать через сокет произвольный доступ? за иключением лени…

memfd_create + /proc/self/fd/ не подойдет?

Вопрос заключался в том, как открыть её как файл, передать путь к файлу и открыть его (open(), fopen()).

Опиши сценарий использования.

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

memfd_create + /proc/self/fd/ не подойдет?

Нельзя открыть файл повторно (а это нужно) и слишком новая фича, на целевой машине может отсутствовать.

секретные подробности

Они не секретные, просто за рамками темы этого треда, описаны в соседнем треде.

Опиши сценарий использования.

Процесс создаёт файл, пишет в него, передаёт путь другому коду (в библиотеке), тот открывает его, читает-пишет, читать/писать/повторно открывать его может только этот же процесс.

Напиши тогда целевую версию ядра, что ли.

Напиши тогда целевую версию ядра, что ли.

Centos 7.5, а какое там ядро, я не знаю, в моём распоряжении его нет, знаю только, что достаточно старое.

Судя по англ. википедии 3.10.0.

Если ты так пытаешься в безопасность - то нет. Может и да, с помощью selinux и/или cgroups, но всё равно нет, в общем случае. Лучше на прикладном уровне решить эту проблему, и просто зашифровать данные.

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

Вообще говоря, задача нерешаемая. Даже если ты откроешь файл через memfd, чтобы не было промежутка времени, где файл доступен по имени, всё равно доступ можно получить через procfs, которая в линуксах всегда смонтирована.

Разве что как-то обернуться в mnt namespace, смонтировать там tmpfs, возможно через FUSE, и тогда вроде как другим процессам содержимое tmpfs не будет видно. Но я не уверен, что любопытные процессы не смогут залезть в этот namespace поглядеть.

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

всё равно доступ можно получить через procfs

Как это происходит? Т.е. как это делается?

В /proc/$pid/fd/ лежат символьные ссылки на открытые процессом $pid файлы. Если процесс создал-открыл-удалил файл, то этот файл часто считается приватным для процесса, потому что его нельзя открыть по имени. Но через символьные ссылки в procfs такой файл открыть вполне можно, поэтому это не является защитой. Этот трюк скорее нужен чтобы не оставлять за собой мусор. Когда закрывается последний дескриптор, указывающий на файл, он автоматически удаляется файловой системой.

Чёрт, это поворот. Спасибо.