☰

Отказано в доступе: cd в каталог

tag-icon • tag-icon linux permissions chrome-os
Отказано в доступе: cd в каталог

Я использую Chromebook и хотел бы перейти внутрь контейнера Android через оболочку. Контейнер смонтирован по пути /run/containers/android_XXXXX. При попытке cdвойти в каталог мне сообщается Permission Denied. Я пробовал запустить команду как sudo, но по какой-то причине cdкоманда становится недоступной. Я запустил chmod u+xв каталоге, но ничего не вышло.

Какие шаги я могу предпринять дальше?

Я запустил statкаталог, который возвращает следующее:

  File: ‘android_XXXXXX/’
  Size: 80              Blocks: 0          IO Block: 4096   directory
Device: fh/15d  Inode: 59640       Links: 3
Access: (0700/drwx------)  Uid: (655360/ UNKNOWN)   Gid: (655360/ UNKNOWN)
Context: u:object_r:tmpfs:s0
Access: 2016-10-31 04:04:52.680000040 +0000
Modify: 2016-10-31 04:04:52.200000040 +0000
Change: 2016-10-31 04:44:54.990001186 +0000
 Birth: -

решение1

Каталог создан drwx------таким образом, что прочитать его или войти в него может только тот, чей uid 655350(который не указан в файле паролей).

sudo cdНевозможность найти cdкоманду ожидаема, она встроена в оболочку. Если бы она не была встроена, то не работала бы. Допустим, ваша текущая оболочка имеет идентификатор процесса 54000, вы запустили команду /bin/cd, это может быть PID 54309. Она сменит каталог для процесса 54309, а затем завершит работу. Процесс 54000 все еще будет в своем исходном каталоге.

chmod u+xизменяет user (owner)разрешение.

То, что вы хотите, этоsudo chmod go+rx /run/containers/android_XXXXX

решение2

Помимо проверки разрешений, о которой упомянул @icarus, вам также необходимо проверить свои ACL (списки контроля доступа), чтобы getfaclубедиться в отсутствии правил, переопределяющих основные привилегии доступа к файлам.

ПРИМЕЧАНИЕ: Если getfaclв вашей системе его нет, то, скорее всего, проблема не в нем.

Пример ACL, который не должен вызывать проблем.

$ getfacl test/

# file: test/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Это означает, что не применяются никакие дополнительные правила ACL, кроме стандартных правил доступа POSIX. Вы можете видеть, что это соответствует выводу ls -aldс точки зрения разрешений. (Аргумент -dto lsговорит ему, что нужно показать сам каталог, а не его содержимое.)

$ ls -ald test/

drwxr-xr-x 2 root root 4096 May  8 19:11 test/

Пример ACL, который может вызвать у вас проблемы.

$ getfacl test/

# file: test/
# owner: root
# group: root
user::rwx
user:mc:r--
group::r-x
mask::r-x
other::r-x

$ ls -ald test/

drwxr-xr-x+ 2 root root 4096 May  8 19:11 test/

В этом случае, глядя на вывод ls -ald, вы бы не подумали, что будет проблема. Однако, поскольку правила ACL применяются поверх правил POSIX, пользователь mcне сможет перейти в каталог из-за отсутствия у него разрешений на выполнение, несмотря на то, что другие наборы разрешений в противном случае предоставили бы их mc.

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

Arch Wiki содержит больше информации о ACL. Проверьтеhttps://wiki.archlinux.org/title/Списки_контроля_доступаесли вам интересно узнать о них больше.

Понятно, что вы можете не захотеть всегда проверять, getfaclявляется ли это вашей проблемой, или вы можете забыть это сделать. К счастью, ls -alсообщает вам, когда применяются дополнительные правила ACL. Если вы посмотрите на вывод ls -al, вы можете увидеть +в конце списка битов разрешений всякий раз, когда применяются правила ACL, и он не показывает ничего иного (по крайней мере, так кажется в моем коротком тестировании).

TLDR: Если вы видите +в списке разрешений из ls -al, проверьте список контроля доступа ( getfacl).

Связанный контент