Почему в файловой системе AFS я не могу получить доступ к некоторым каталогам, для которых у меня есть разрешения rx, и к тем, где у меня нет разрешений?

Question

Я столкнулся с неожиданным поведением при попытке доступа к каталогам в монтировании AFS с использованием Linux (в частности, в bash 4.3.11 (1)-релизе на Ubuntu 14.04.1). В некоторых случаях я не могу получить доступ к каталогам, к которым я должен иметь доступ, а в других я могу получить доступ к некоторым каталогам, где у меня вообще нет разрешений. Например:

$ ls -l
total 24
drwxr-xr-x 9   70296     root     6144  Jan 12 14:44 look_inside
drwx------ 278 someadmin operator 10240 Jan 17 17:54 private
<output truncated>
$ cd look_inside
-bash: cd: look_inside: Permission denied
$ ls look_inside
ls: cannot open directory look_inside: Permission denied

Я не владелец и я не в root группы, поэтому все права должны применяться к look_inside. У каждого есть права r-x для look_inside и всех его родительских каталогов, но я не могу использовать cd look_inside или ls look_inside . С другой стороны, я могу получить доступ к private , хотя у меня нет разрешений:

$ getfacl private
# file: private
# owner: cbl
# group: operator
user::rwx
group::---
other::---
$ ls -l private
total 560
<output truncated>

Я тоже не владелец private . Я работаю в групповом operator , но это не должно иметь значения, так как у группы нет прав для private . И все же, я могу получить доступ к приватной. Тем не менее, я не могу получить доступ ни к одному из каталогов внутри него, независимо от того, есть ли у меня разрешения r-x (см. Ниже). Это имеет смысл, конечно, потому что у меня нет разрешения x на их родителей. Обычных файлов в private (или, по крайней мере, мне показываются каталоги только при запуске ls), поэтому я не знаю, как это влияет на обычные файлы.

$ cd private
$ ls -l
total 560
drwx------ 3 someadmin  operator 2048 Jan 16 14:11 someuser
drwxr-xr-x 3 otheradmin operator 2048 Jan 16 14:11 otheruser
<output truncated>
$ ls -l someuser
ls: cannot open directory someuser: Permission denied
$ ls -l otheruser
ls: cannot open directory otheruser: Permission denied

Что может быть причиной такого поведения? Есть ли способ для меня, чтобы получить доступ к look_inside? Должен ли я (или системный администратор) беспокоиться о том, что я могу получить доступ к private?

Answer 1

AFS не использует традиционные разрешения Unix (хотя и запоминает их) и списки доступа POSIX (что вы видите в getfacl). Есть некоторые исключения с разрешениями Unix (если вы удалите все права на чтение или запись с помощью chmod , я считаю, что это удалит соответствующий доступ для всех), но в целом AFS использует собственную систему ACL.

Предполагая, что вы используете OpenAFS, чтобы увидеть разрешения для файла или каталога, запустите fs listacl <path> . Чтобы установить разрешения, если у вас есть доступ, запустите fs setacl <path> <user> <perms> . Разрешения, предоставляемые списками ACL AFS, отличаются от разрешений Unix chmod -style, списков ACL POSIX и любой другой системы доступа, о которой я знаю. Они подробно объясняются здесь, но кратко: у вас есть 7 разрешений, обычно представленных одной буквой. Это: 'r'ead,' l'ist, 'w'rite,' i'nsert, d'elete, loc'k 'и' a'dmin.

Например, каталог, в котором вы можете просматривать и читать файлы, будет выглядеть так:

$ fs listacl somedir
Access list for somedir is
Normal rights:
   system:anyuser rl
   system:administrators rlidwka

Это означает, что 'system:anyuser' (любой в мире) может только 'l' содержимое каталога и «читать» содержимое файлов в этом каталоге. С другой стороны, система: администраторы (группа, используемая для пользователей с правами администратора) может делать все что угодно.

Каталог, к которому вы не можете получить доступ, может выглядеть так:

$ fs listacl privdir
Access list for privdir is
Normal rights:
   system:administrators rlidwka
   foouser rlidwka

Это означает, что только администраторы и «foouser» могут делать что-либо с этим каталогом. Однако, если вы не можете получить доступ к каталогу на всех, я думаю , вы также не сможете fs listacl его, так что появится сообщение об ошибке.

Если вы не используете OpenAFS, а используете реализацию AFS в исходном дереве исходных текстов Linux ("kAFS"), у вас не будет команды fs . Я не верю, что можно просматривать списки управления доступом AFS с этой реализацией, но я могу ошибаться в этом.

Answer 2

Списки контроля доступа могут сделать это. Вы проверяли свое имя пользователя и группы в сеансе bash? whoami и groups