Озвучь уже, чего на самом деле хочешь добиться. А то сперва как файл в память замаппить, теперь это. В зависимости от настоящей цели будет разный вариант, как это сделать.
Да всё та же задача, либа принимает путь к файлу, читает, пишет туда оттуда, потом вызывающий процесс забирает результат из этого файла, но ни какой больше процесс не должен иметь даже возможности заглянуть в этот файл.
эм.. пишет туда/сюда в файл?!
меня это смущает… но можно и так если осторожно, а что shm не подходит? там и права выставляются… а в unix сокетах можно вообще асинхронно + tls1.2 внутри поднять :D
Это не оно? Если кратко, то 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, и то их оттуда убрали.
Процесс создаёт файл, пишет в него, передаёт путь другому коду (в библиотеке), тот открывает его, читает-пишет, читать/писать/повторно открывать его может только этот же процесс.
Если ты так пытаешься в безопасность - то нет. Может и да, с помощью selinux и/или cgroups, но всё равно нет, в общем случае. Лучше на прикладном уровне решить эту проблему, и просто зашифровать данные.
Но вообще, это вопрос модели безопасности, договоритесь сначала с заказчиком (даже если это ты сам), кто такой злоумышленник, и сколько ресурсов ему будет невыгодно потратить на доступ к файлу.
Вообще говоря, задача нерешаемая. Даже если ты откроешь файл через memfd, чтобы не было промежутка времени, где файл доступен по имени, всё равно доступ можно получить через procfs, которая в линуксах всегда смонтирована.
Разве что как-то обернуться в mnt namespace, смонтировать там tmpfs, возможно через FUSE, и тогда вроде как другим процессам содержимое tmpfs не будет видно. Но я не уверен, что любопытные процессы не смогут залезть в этот namespace поглядеть.
механизмам межпроцессного взаимодействия более 20 лет. там ничего не поменялось. нет нужды искать там фантастических тварей. при дискретной системе доступа такого не реализовано. см мандатная система доступ астра линукс, про selinux уже писали выше. но если васянская либа требует секретную инфу в контексте файловой системы значит так и нужно, так решено дядей васей.
В /proc/$pid/fd/ лежат символьные ссылки на открытые процессом $pid файлы. Если процесс создал-открыл-удалил файл, то этот файл часто считается приватным для процесса, потому что его нельзя открыть по имени. Но через символьные ссылки в procfs такой файл открыть вполне можно, поэтому это не является защитой. Этот трюк скорее нужен чтобы не оставлять за собой мусор. Когда закрывается последний дескриптор, указывающий на файл, он автоматически удаляется файловой системой.