Какова цель соединения olpc-mesh в nmcli

umask является вычитающим, а не предписывающим: биты разрешения, установленные в umask, по умолчанию удаляются из режимов, заданных программами, но umask не может добавить биты разрешения. touch по умолчанию задает режим 666 (ссылка дана на реализацию GNU, но другие ведут себя так же; это определено POSIX), поэтому результирующий файл получает режим, маскируемый текущим umask: в вашем случае, поскольку umask ничего не маскирует, результат - 666.

Режим файла или каталога обычно задается программой, которая его создает; большинство системных вызовов, участвующих в этом, принимают режим (например, open(2), creat(2), mkdir(2) все имеют параметр mode; но fopen(2) не имеет, и использует режим 666). Если в родительском каталоге не указан ACL по умолчанию, то umask процесса на момент вызова используется для маскировки указанного режима (побитовая операция mode & ~umask; фактически это вычитание каждого набора разрешений в umask из режима), поэтому umask может только уменьшить режим, но не увеличить его. Если в родительском каталоге указан ACL по умолчанию, он используется вместо umask: результирующие разрешения файла являются пересечением режима, указанного программой создания, и режима, указанного ACL по умолчанию.

POSIX указывает, что режим по умолчанию должен быть 666 для файлов, 777 для каталогов; но это только документация по умолчанию (т.е., при чтении POSIX, если программа или функция не указывает режим файла или каталога, применяется режим по умолчанию), и это не обеспечивается системой. В общем случае это означает, что POSIX-совместимые инструменты указывают режим 666 при создании файла и режим 777 при создании каталога, а umask вычитается из этого значения; но система не может обеспечить это, потому что есть много законных причин использовать другие режимы и/или игнорировать umask:

• компиляторы, создающие исполняемый файл, пытаются создать файл с установленными исполняемыми битами (при этом они применяют umask);
• chmod(1) явно определяет режим в зависимости от своих параметров, и игнорирует umask, когда указано "who", или режим полностью задан (так chmod o+x игнорирует umask, как и chmod 777, но chmod +w применяет umask);
• инструменты, которые сохраняют права доступа, применяют соответствующий режим и игнорируют umask: например, cp -p, tar -p;
• инструменты, которые принимают параметр, полностью определяющий режим, также игнорируют umask: install --mode, mknod -m...

Таким образом, вы должны думать о umask как об указании битов разрешения, которые вы не хотите видеть установленными по умолчанию, но помните, что это всего лишь запрос. Вы не можете использовать его для указания битов разрешения, которые вы хотите видеть установленными, только те, которые вы хотите видеть неустановленными. Более того, любой процесс может изменить свою umask в любом случае, используя umask(2) системный вызов! Системный вызов umask(2) также является единственным определенным POSIX способом для процесса узнать свой текущий umask (наследуемый от родителя). В Linux, начиная с ядра 4.7, вы можете узнать текущий umask процесса, найдя Umask в /proc/${pid}/status.

(Для полноты картины упомяну, что поведение относительно setuid, setgid и sticky-битов зависит от системы, а удаленные файловые системы, такие как NFS, могут добавить свои собственные изюминки)

.