Управление ресурсами systemd через CGroup

Вы не можете изменить среду этого процесса извне, но если вам действительно нужно, вы можетеptrace(2)процесс (на самом деле поток, но я буду продолжать говорить процесс для простоты )с адекватный инструмент для внесения изменений из в текущий процесс . Конечно, было бы странно полагаться на ptraceдля производственного использования, но если бы это был единственный оставшийся выбор...

gdbэто можно сделать

Вы можете присоединиться к процессу (или нескольким потокам с большим количеством gdb -fu )и заставить его изменить свое поведение и отсоединиться от него. Если сделать это достаточно быстро (, т.е. :заскриптовать ), процесс не станет мудрее. В зависимости от запущенного процесса и его действий при инициализации, вы не всегда можете ptraceот одного и того же пользователя, а затем требуется root-доступ или хотя быCAP_SYS_PTRACEвозможность . То, что делается с процессом, на самом деле делается им самим:если процессу уже разрешено изменять свои возможности (обычно требуется CAP_SETPCAP), то можно заставить себя сделать это. Если это не разрешенное действие, то ptraceне поможет, даже если это сделано пользователем root. Точно так же легко закрыть файл журнала и снова открыть его в другом месте.

Примеры с некоторыми UL Q/A, некоторые из них мои:

• Как найти связь между интерфейсом tap и его файловым дескриптором?:Обходной путь, поскольку ядро ​​не предоставляло эту информацию через /proc/pid/fdinfo/ до версии ядра 3.14.

• как отменить общий доступ к сети для текущего процесса:запущенный gdb на (навсегда )изменить сетевое пространство имен процесса и эффективно изолировать его от сети.

• Остановить программу от записи в удаленный файл.:Заставить программу изменить свой неиспользуемый файл журнала. Это ответ на второй пример в вашем вопросе.

Чтобы ответить на первый пример вашего вопроса...

Ограничение возможностей запущенного процесса с помощью gdb

Пример будет выполняться в оболочке bash, работающей от имени пользователя root (, что дает полные возможности )с использованием gdb(, также работающего от имени пользователя root ). Это довольно запутанно, потому чтоlibcap функции неизвестны, если программа не была связана с ним, поэтому я выбрал более простой, но более утомительный (, потому что он требует манипулирования структурами )метод, который не требует ни среды разработки, ни дополнительного gdb -fu :, напрямую используя определения системных вызовов, которые всегда известны в gdb.

Термин1:

# echo test > /tmp/test
# chown nobody /tmp/test
# chmod 600 /tmp/test
# cat < /tmp/test
test
# cat /tmp/test
test
# echo $$
5237
# grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
#

Термин2:

# gdb -q -p 5237
Attaching to process 5237
Reading symbols from /bin/bash...(no debugging symbols found)...done.

[...]

0x00007fb774737681 in pselect () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) set $malloc=(void *(*)(long long)) malloc
(gdb) print $malloc(4*(2+3*2))
$1 = (void *) 0xc4ecc8
(gdb) set *((unsigned int *)($1))=0x20080522
(gdb) set *((unsigned int *)($1)+1)=getpid()
(gdb) print capget($1, (unsigned int *)$1+2)
$2 = 0
(gdb) set *((unsigned int *)($1)+2) &= ~(1<<1|1<<2)
(gdb) print capset($1, (unsigned int *)$1+2)
$3 = 0
(gdb) call free($1)
$4 = 0
(gdb) quit
A debugging session is active.

    Inferior 1 [process 5237] will be detached.

Quit anyway? (y or n) y
Detaching from program: /bin/bash, process 5237
# 

Таким образом, эта выделенная память, 64-битный стиль обхода , для необходимых структур*cap_user_header_tи cap_user_data_t[2], установите некоторое магическое значение , извлеките текущее возможности процесса и удалилиCAP_DAC_OVERRIDEиCAP_DAC_READ_SEARCHиз набора эффективных возможностей, тем самым предотвратив чтение /tmp/test, и, наконец, освободили выделенную память.

Назад в семестр1:

# grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003ffffffff9
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
# cat < /tmp/test
bash: /tmp/test: Permission denied
# cat /tmp/test
test
#

Какая разница? Процесс bash больше не может получить доступ к корневому файлу, отличному от -, с его ограниченным доступом при использовании перенаправления и терпит неудачу (после разветвления, но перед выполнением -cat). Когда (разветвление и )выполнение -нового процесса, root восстанавливает все свои возможности , если они еще не удалены из --другого -набора :ограничивающий набор возможностей, который можно изменить другим способом(prctl(PR_CAPBSET_DROP,...)). Вот почему запуск catбез перенаправления по-прежнему работает нормально (для root).