Предусматривается ли в документации pivot_root () возможность монтирования пространств имен?

С данными вашего примера и grep с активированными регулярными выражениями perl (PCRE) (-P):

grep -oP '\xFF\xD8.*\xFF\xD9' input >image.jpeg

Флаг -o говорит grep выводить только совпадающую часть. Тест после выглядит многообещающе:

$ file image.jpeg
image.jpeg: JPEG image data

Edit: Если вышеописанное не сработает, и придется sed, нужно преобразовать данные в текст:

hexdump -ve '1/1 "%.2X"' input | sed 's/.*\(FFD8.*FFD9\).*/\1/' | xxd -r -p >image.jpeg
  • С помощью hexdump файл input преобразуется в последовательность, подобную той, что в вашем вопросе.
    • -e задает формат
    • 1/1 означает применить формат 1 раз (количество итераций), а 1 после / задает количество байт, интерпретируемых каждой итерацией (количество байт).
    • %.2X - это формат: двузначное шестнадцатеричное значение.
  • Затем sed удаляет из дампа все до FFD8 и после FFD9. дампа.
    • Скобки \(...\) указывают на подшаблон, который мы хотим сохранить на потом
    • Замените все на \1, который является содержимым подшаблона сверху.
  • По крайней мере, xxd переводит hexdump в двоичный формат.

Тест проходит успешно, если использовать пример из вашего вопроса:

$ echo 0a 55 57 5d 50 cf ff d8 ff fe ff ff ff d9 df 47 fe e7 c9 3b e9 9b 6b 55 c4 57 9b 98 73 fd 15 f7 77 7e f7 95 dd 55 f7 55 05 cc 55 97 55 dd 62 d1 1f 51 ef f1 ef fb e9 bf ed 5f bf f2 9d 75 af fe 6b fb bf 8f f7 f7 7e ff d3 bf 8e d5 5f df 57 75 fe 77 7b bf d7 af df 5d fb 0a 47 de d5 ff c1 23 9b 20 08 20 65 3c 06 83 11 05 30 50 a0 20 55 20 84 41 04 c2 59 50 89 64 44 44 10 05 20 87 28 1d a9 | \
  xxd -r -p | \
  hexdump -ve '1/1 "%.2X"' | \
  sed 's/.*\(FFD8.*FFD9\).*/\1/' | \
  xxd -r -p >image.jpeg
$
$ file image.jpeg
image.jpeg: JPEG image data
$ xxd image.jpeg
0000000: ffd8 fffe ffff ffd9                      ........
4
15.02.2019, 10:47
1 ответ

It sounds like the alternative implementation of pivot_root() would put the calling process in a new, altered mount namespace. Is that a valid reading?

No. En mi opinión, esto no está muy claro, pero hay una lectura mucho más consistente y correcta.

La parte esencial de pivote _raíz (), que debe ser la misma en cualquier implementación, es:

pivot_root() moves the root filesystem of the calling process to the directory put_old and makes new_root the new root filesystem of the calling process.

La ​​parte esencial de pivote _raíz ()no se limita solo al proceso de llamada. La operación descrita en esta cita funciona en el espacio de nombres de montaje del proceso de llamada. Afectará la vista de todos los procesos en el mismo espacio de nombres de montaje.

Considere el efecto que tiene el cambio esencial en un segundo proceso -o subproceso del núcleo -cuyo directorio de trabajo era el antiguo sistema de archivos raíz. Su directorio actual seguirá siendo el antiguo sistema de archivos raíz. Esto mantendrá ocupado el punto de montaje /put_oldy, por lo tanto, no será posible desmontar el antiguo sistema de archivos raíz.

Si controla este segundo proceso, resuelva esto, según la página de manual, configurando su directorio de trabajo en la nueva raíz _antes de que se llame a la raíz ()del pivote _. Después de llamar a pivote _raíz (), su directorio actual seguirá siendo el nuevo sistema de archivos raíz.

Entonces, el proceso S (ystemd )se configuró para señalar al proceso P (lymouth ), para cambiar el directorio de trabajo antes de que S llame a pivot _root (). No hay problema. Pero también tenemos subprocesos del núcleo, que comienzan en /. La implementación actual de pivot _root ()se ocupa de los subprocesos del kernel por nosotros; es equivalente a configurar los directorios de trabajo de los subprocesos del kernel y cualquier otro proceso en new_rootantes de la parte esencial de pivot _root ().

Excepto, la implementación actual de pivot _root ()solo cambia el directorio de trabajo de un proceso si el directorio de trabajo anterior era /. Entonces, en realidad es bastante fácil ver la diferencia que esto hace:

$ unshare -rm
# cd /tmp    # work in a subdir instead of '/', and pivot_root() will not change it
# /bin/pwd
/tmp
# mount --bind /new-root /new-root
# pivot_root /new-root /new-root/mnt
# /bin/pwd
/mnt/tmp    # see below: if pivot_root had not updated our current chroot, this would still show /tmp

vs.

$ unshare -rm
# cd /
# /bin/pwd
/
# ls -lid.
2 dr-xr-xr-x. 19 nfsnobody nfsnobody 4096 Jun 13 01:17.
# ls -lid /newroot
6424395 dr-xr-xr-x. 20 nfsnobody nfsnobody 4096 May 10 12:53 /new-root
# mount --bind /new-root /new-root
# pivot_root /new-root /new-root/mnt
# /bin/pwd
/
# ls -lid.
6424395 dr-xr-xr-x. 20 nobody nobody 4096 May 10 12:53.
# ls -lid /
6424395 dr-xr-xr-x. 20 nobody nobody 4096 May 10 12:53 /
# ls -lid /mnt
2 dr-xr-xr-x. 19 nobody nobody 4096 Jun 13 01:17 /mnt

Ahora entiendo lo que sucede con el directorio de trabajo, me resulta más fácil entender lo que sucede con chroot (). El chroot actual del proceso que llama a pivot _root ()puede ser una referencia al sistema de archivos raíz original, tal como puede ser su directorio de trabajo actual.

Tenga en cuenta que si hace chdir ()+pivot _root ()pero olvidó hacer chroot (), su directorio actual estaría fuera de su chroot actual. Cuando su directorio actual está fuera de su chroot actual, las cosas se vuelven bastante confusas. Probablemente no desee ejecutar su programa en este estado.

# cd /
# python
>>> import os
>>> os.chroot("/newroot")
>>> os.system("/bin/pwd")
(unreachable)/
0
>>> os.getcwd()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 2] No such file or directory
>>> os.system("ls -l./proc/self/cwd")
lrwxrwxrwx. 1 root root 0 Jun 17 13:46./proc/self/cwd -> /
0
>>> os.system("ls -lid./proc/self/cwd/")
2 dr-xr-xr-x. 19 root root 4096 Jun 13 01:17./proc/self/cwd/
0
>>> os.system("ls -lid /")
6424395 dr-xr-xr-x. 20 root root 4096 May 10 12:53 /
0

POSIX no especifica el resultado de pwdo getcwd ()en esta situación :). POSIX no advierte que podría obtener un error "No existe tal archivo o directorio" (ENOENT )de getcwd (). Las páginas de manual de Linux señalan que este error es posible, si el directorio de trabajo se desvinculó (, p. conrm). Creo que este es un muy buen paralelo.

4
27.01.2020, 20:55

Теги

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