shm_open непонятка с правами доступа

umask?

Create the shared memory object if it does not exist. The user and group ownership of the object are taken from the corresponding effective IDs of the calling process, and the object’s permission bits are set according to the low- order 9 bits of mode, except that those bits set in the process file mode creation mask (see umask(2)) are cleared for the new object. A set of macro constants which can be used to define mode is listed in open(2). (Symbolic definitions of these constants can be obtained by including <sys/stat.h>.)

umask?

Вполне возможно, однако я не понял когда и как его использовать?

umask(0666) нужно вызывать до создания объекта или после?

До

https://ru.manpages.org/umask/2

Типичным значением umask в процессе является S_IWGRP | S_IWOTH (восьмеричное 022). Обычно, когда аргумент mode у open(2) задаётся как:

S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH

(восьмеричное 0666) при создании файла, права получившегося файла будут:

S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH

(так как 0666 & ~022 = 0644; т.е., rw-r–r–).

(так как 0666 & ~022 = 0644; т.е., rw-r–r–).

Извините, все равно не понял как и когда этим umask пользоваться.

Наверное я совсем заработался, но я понять не могу, когда этот umask вызывать и с каким значением? До shm_open или после? И какое значение передавать в umask?

До open и передай 0.

До open и передай 0.

Спасибо огромное!

Получилось.

Однако man написан непонятным языком.

Вам бы разобраться с концепцией umask и объяснить как-то пользователю вашего будущего приложения почему оно игнорирует umask. Нужен ли на самом деле такой world writable shared object? Нет ли здесь потенциальных уязвимостей?

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

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

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

Вам бы разобраться с концепцией umask и объяснить как-то пользователю вашего будущего приложения почему оно игнорирует umask. Нужен ли на самом деле такой world writable shared object? Нет ли здесь потенциальных уязвимостей?

Концепция umask совершенно не понятна. Какой-то лютый костылинг.

При создании объекта указываются права доступа, но без umask они оказываются другие. Это как вообще?

Что касается потенциальных уязвимостей, то… На данный момент лишь тестирую возможности и применимость для своих нужд. Возможно, что вообще перейду на сокеты. Сокеты понятнее.

Кстати, к shm памяти как-то можно прикрутить poll/epoll?

Внезапно. Если это unix-сокеты то права тоже применяются

Внезапно. Если это unix-сокеты то права тоже применяются

Это я знаю, но не очень понимаю в чем профит unix socket в сравнении с обычными?

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

но не очень понимаю в чем профит unix socket в сравнении с обычными?

Ну гугл же, ёпт. Примитивный вопрос.

На хайлоаде будет меньше загрузка процессора. На нехайлоаде разница утонет в других факторах типа настройки соединений или приложений.