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

848
rhymes_with_dorange

Я столкнулся с неожиданным поведением при попытке доступа к каталогам в монтировании 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?

1
что говорит `df -T .`? greggo 9 лет назад 0
`df -T .` показывает, что типом является afs, и что доступны все блоки (используется 0%). Я не осознавал, что это уместно, что это AFS, но я думаю, из вашего комментария, что это важно. rhymes_with_dorange 9 лет назад 0
Итак, похоже, что обычные разрешения linux не применяются в AFS, даже если `ls -l` с радостью отобразит их. AFS имеет собственную систему разрешений, которая работает только в области каталогов. Информацию о разрешениях каталога можно получить с помощью `fs la directory_name`. Узнав, что это связано с AFS, я смог найти [эту полезную ссылку] (http://kb.mit.edu/confluence/pages/viewpage.action?pageId=3907002). rhymes_with_dorange 9 лет назад 0
@greggo, не могли бы вы ответить на этот вопрос? rhymes_with_dorange 9 лет назад 0
@ рифмуется с дорагой У меня нет ответа; Я просто подумал, что знание файловой системы было бы важно - так как я не видел такого поведения с FS, с которыми у меня был опыт. Спасибо за редактирование вопроса, чтобы указать его AFS. greggo 9 лет назад 0

2 ответа на вопрос

1
adeason

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

Предполагая, что вы используете OpenAFS, чтобы увидеть разрешения для файла или каталога, запустите fs listacl <path>. Чтобы установить разрешения, если у вас есть доступ, запустите fs setacl <path> <user> <perms>. Разрешения, предоставляемые списками ACL AFS, отличаются от chmodразрешений в стиле Unix, списков 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 с этой реализацией, но я могу ошибаться в этом.

0
blues

Access Control Lists can do that. Did you check your username and groups in the bash session? whoami and groups

Да, я проверил имя пользователя и группы, и они оказались такими, как я ожидал. Вывод в `getfacl private` показывает, что здесь нет ACL, верно? rhymes_with_dorange 9 лет назад 0

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