Переключитесь назад и вперед между тюрьмой chroot и Host в том же терминале
bash виртуальные / dev / tcp / host / port файлы (изначально функция ksh) могут использоваться только для подключения сокет для порта TCP.
Если вы хотите сделать больше, например создать прослушивающий сокет и порождать из него принимающие сокеты, этого нельзя сделать с перенаправлением.
zsh поддерживает это через свой модуль zsh / net / tcp и встроенный ztcp .
zmodload zsh/net/tcp
handle-connection() (
IFS= read -ru4 line || exit
print -r "Got: $line"
print -ru4 "Hello $line"
ztcp -c 4
)
ztcp -l -d 3 1234 # create a TCP listening socket on port 1234 on fd 3
while ztcp -ad4 3 # accept connection on fd 4
do handle-connection & exec 4>&-
done
Он по-прежнему ограничен тем, что вы не можете указать адрес для привязки или размер очереди прослушивания, или отключить только одно направление, или установить параметры сокета ... Он также не выполняет UDP или SCTP (вы может работать с сокетами домена Unix с помощью команды zsocket ).
Если вам нужно что-то более интересное или у вас нет zsh, вы можете использовать socat . Например, здесь с экспортированными функциями bash :
handle_connection() {
IFS= read -r line &&
printf 'Hello %s\n' "$line"
}
export -f handle_connection
socat tcp-listen:1234,reuseaddr,fork 'exec:bash -c handle_connection'
С socat возможности безграничны, подробности см. На странице руководства.
Например, чтобы сервер запустил сеанс оболочки:
socat tcp-listen:1234,reuseaddr,fork exec:bash,pty,ctty,setsid,stderr,sane
На стороне клиента вы должны подключиться как:
socat -,raw,echo=0 tcp:host:1234
В традиционном Unix rootможет делать что угодно.
Однако в современных Linux (, возможно, в других Unix ), теперь у него есть возможности. Здесь обсуждается возможность CAP_DAC_OVERRIDE, любой процесс с этой возможностью будет игнорировать права доступа к файлам (, за исключением x, см. другие ответы ).
Большинство систем будут настроены в режиме обратной совместимости, поэтому когда процесс меняет свой эффективный ID пользователя на root, он получает все возможности, а когда эффективный ID пользователя изменяется с root, он теряет возможности.
Существуют способы избежать потери возможностей, это можно использовать для передачи некоторых возможностей процессу, не являющемуся -корневым. Существует также способ получить возможности, не становясь root, это работает так же, как процесс становится root.
Имеет значение эффективный идентификатор пользователя, реальный и сохраненный идентификаторы пользователей дают вам разрешение копировать эти идентификаторы только в один из других идентификаторов (, например, в эффективный идентификатор пользователя ).
SE _linux и пространства имен/группы могут ограничивать действия root.
When a process has an effective or real uid being root and tries to access a file...
Для доступа к файловой системе важен только эффективный UID, а не настоящий UID. Процесс, имеющий привилегированный UID, может перетасовать реальный и эффективный UID, чтобы временно отказаться от привилегий.
# perl -MEnglish -e '$EUID = 65534; system "id"; system "cat /etc/shadow"'
uid=0(root) gid=0(root) euid=65534(nobody) groups=0(root)
cat: /etc/shadow: Permission denied
Но кроме этого, вы правы, наличие привилегий позволяет получать доступ к файлам независимо от битов разрешения. (Помимо того факта, что выполнение файла не работает, если в нем не установлен хотя бы один xбит, но на самом деле это не более чем удобство. Если у вас есть привилегии, вы обычно можете просто скопировать файл и запустить его или сначала изменить разрешения.)
См., например,. заключительная часть справочной страницы Linux path_resolution(7)(«Обход проверок разрешений :суперпользователь и возможности» )или текст в POSIX(«4.5 Разрешения на доступ к файлам» ).
Как и в последних подсказках, и в первых утверждениях, фактическая проверка на привилегированность может быть не только UID. В Linux это на самом деле возможностьCAP_DAC_OVERRIDE(или CAP_DAC_READ_SEARCHв меньшей степени ). Я не знаю деталей других систем.
Для привилегированного пользователя оценивается только бит x.
Это означает, что для того, чтобы суперпользователь мог выполнять файл, должен быть установлен хотя бы один бит x.
Все остальные разрешения суперпользователя игнорируются.
Корень будет иметь доступ ко всему, независимо от битов разрешения. Исключением является то, что корневой процесс не будет пытаться выполнить файл, если ни один из битов выполнения не установлен, а ограничения установлены SELinux.
Тем не менее, root по-прежнему сможет устанавливать нужные биты выполнения и изменять правила SELinux, поэтому вы ничего не можете сделать, чтобы предотвратить доступ root к вашим файлам.
Редактировать
Из "пути человека _разрешение"
On a traditional UNIX system, the superuser (root, user ID 0) is all-powerful, and bypasses all permissions restrictions when accessing files.
Вы не можете скрыть что-либо от root , если только вы не используете шифрование, и даже тогда root все равно может это удалить!