Вопросы Теги

Как сделать /dev внутри пространств имен linux

Сделайте это как Amazon --сгенерируйте для них пару ключей открытый/закрытый и отправьте им закрытый ключ. Им нужно будет отправить этот закрытый ключ для аутентификации (ssh -i /path/to/key.pem user@host), и таким образом вам никогда не потребуется включать аутентификацию по паролю SSH.

РЕДАКТИРОВАТЬ:Благодаря комментаторам, я наконец-то понимаю, откуда они берутся. Чтобы первоначально поделиться закрытым ключом с пользователем, он должен быть отправлен по безопасному каналу, такому как HTTPS.

3
02.09.2019, 00:49
1 ответ

Быстрое решение вашей проблемы :смонтируйте tmpfsс параметром mode=(, который устанавливает разрешения корневого каталога файловой системы ), и используйте режим без либо липкий бит (01000), либо разрешение на запись для других (002)--, которые оба на по умолчанию:

root@host:~/test# mount -o mode=0755 -t tmpfs none dev/

Вы ничего не теряете; наличие каталога /devвнутри вашего контейнера, доступного для записи всем, не было хорошей идеей с самого начала (было бы интересно узнать, делает ли это Docker;-))

Это происходит из-за tmpfsмонтирования внутри пользовательского пространства имен :ядро ​​устанавливает владельца корневого каталога файловой системы tmpfsиз непереведенных учетных данных процесса, выполняющего монтирование (, откуда uid=1000,gid=1000в выводе mount(1)), а его разрешения по умолчанию01777(rwxдля всех + липкий бит ).

Сочетание не -корневого владельца, разрешений на запись для других(S_IWOTH)и фиксированного бита(S_ISVTX)в каталоге вызывает любопытное поведение в более новых ядрах Linux :, пытающихся open(2)существующий символ устройство внутри такого каталога выйдет из строя с EACCES, если используется флаг O_CREAT, даже если это сделал владелец каталога:

$ mkdir doo; chmod 1777 doo 
$ su -c 'mknod -m 666 doo/null c 1 3'  # or touch doo/null; mount -B /dev/null doo/null 
$ echo > doo/null
bash: doo/null: Permission denied

$ perl -MFcntl -e 'sysopen(NULL, "doo/null", O_WRONLY|O_CREAT, 0666) or die $!'
Permission denied at -e line 1.
$ perl -MFcntl -e 'sysopen(NULL, "doo/null", O_WRONLY, 0666) or die $!'
$ # ok!

$ chmod -t doo
$ echo > doo/null
$ # ok!

Это воспроизводится в Debian Buster / 4.19.0 -5 и в более поздних ядрах, но не в Debian Stretch / 4.9.0 -4.

Такое поведение было введено как побочный эффект этой фиксации :

. 
commit 30aba6656f61ed44cba445a3c0d38b296fa9e8f5
Author: Salvatore Mesoraca <s.mesoraca16@gmail.com>
Date:   Thu Aug 23 17:00:35 2018 -0700

    namei: allow restricted O_CREAT of FIFOs and regular files
...
diff --git a/fs/namei.c b/fs/namei.c
...
+static int may_create_in_sticky(struct dentry * const dir,
+                               struct inode * const inode)
+{
+       if ((!sysctl_protected_fifos && S_ISFIFO(inode->i_mode)) ||
+           (!sysctl_protected_regular && S_ISREG(inode->i_mode)) ||
+           likely(!(dir->d_inode->i_mode & S_ISVTX)) ||
+           uid_eq(inode->i_uid, dir->d_inode->i_uid) ||
+           uid_eq(current_fsuid(), inode->i_uid))
+               return 0;
+
+       if (likely(dir->d_inode->i_mode & 0002) ||
+           (dir->d_inode->i_mode & 0020 &&
+            ((sysctl_protected_fifos >= 2 && S_ISFIFO(inode->i_mode)) ||
+             (sysctl_protected_regular >= 2 && S_ISREG(inode->i_mode))))) {
+               return -EACCES;
+       }
+       return 0;
+}

doo/nullне очистит первый if, потому что это не fifo и не обычный файл, в содержащем каталоге действительно установлен фиксированный бит, а его uid отличается от идентификатора каталога и от идентификатора каталога. процесс пытается его открыть.

Он будет немедленно соответствовать второму if, потому что в содержащем каталоге установлен бит002(записи -для -других ).

Я не нашел в обсуждениях lkml, где это было введено(1 , 2 , 3 ), рассматривался ли вообще этот эффект. В любом случае, помещение символьных устройств в мир -записываемых липких каталогов вряд ли будет преднамеренным.

3
27.01.2020, 21:20

Теги

Похожие вопросы