Как обновить настройки пользователя / группы запущенного процесса?

Следующий сценарий распечатывает самые длинные пути в файловой системе и/или ниже текущего каталога, но вместо использования find, это использует в своих интересах существующее locate база данных (потенциально очень длинных) путей без искать/пересекать (потенциально очень глубокие) структуры каталогов. Обратите внимание, что это считает каталоги для определения глубины, не только длины пути (но и это могло легко быть изменено/упрощено, чтобы сделать любого).

$ cat find-longest-path.sh
#!/bin/bash
pattern=$1
locate -r "^${PWD}/${pattern}" \
   | while read f; do printf "$(tr -cd / <<< "$f" | wc -c):$f\n"; done \
   | sort -nr -t: -k1 \
   | head -5

Это распечатывает самые глубокие 5 путей (head -5) из шаблона имени файла (regexp) начинающий с pwd. Вывод снабжается префиксом глубиной (т.е. количество /в пути). Для поиска просто определенного имени файла и/или шаблона, где угодно в файловой системе, удаляют $PWD и просто поиск locate -r /some_file$ (... и т.д., и т.д.).

Например,

$ ./find-longest-path.sh 'foo.*log$'
5:/path/to/deep/path/foo-12345.log
3:/path/to/shallow/foobar.log
5
10.06.2015, 18:18
2 ответа

Очень интересная попытка. На самом деле, дополнительные группы процесса (определенные в / etc / group ) устанавливаются SetGroups System Call. Это требует CAP_SETGID Привилегия или быть корнем.

Так что вы можете поделать это:

# id
uid=0(root) gid=0(root) groups=0(root)

# gdb -q id
Reading symbols from id...(no debugging symbols found)...done.
(gdb) b getgroups
Breakpoint 1 at 0x401990
(gdb) run
Starting program: /usr/bin/id 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, getgroups () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) call setgroups(5, {1, 2, 3, 4, 5})
$1 = 0
(gdb) d 1
(gdb) c
Continuing.
uid=0(root) gid=0(root) groups=0(root),1(daemon),2(bin),3(sys),4(adm),5(tty)
[Inferior 1 (process 8059) exited normally]
(gdb) 
2
27.01.2020, 20:41

Похоже, занятие бессмысленное.

Целевой процесс не только может не иметь всех прав, необходимых для переключения учетных данных, но и может иметь где-то хранящийся и активно используемый uid / gid, поэтому неожиданное изменение учетных данных может действительно нарушить работу.

Существуют различные объекты, которые знают, кому они принадлежат - файлы, sysv ipc.

Итак, вам нужно будет / остановить / все целевые процессы и обновить все возможные места.

Но некоторые процессы могут быть заблокированы в ядре без прерывания - что теперь?

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

Или другими словами: чего вы на самом деле пытаетесь достичь и почему?

1
27.01.2020, 20:41

Теги

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