Почему системный вызов rename () запрещает перемещение каталога, который я не могу записать в другой каталог? - PullRequest
1 голос
/ 31 марта 2010

Я пытаюсь понять, почему это дизайнерское решение было принято с помощью системного вызова rename () в 4.2BSD. Здесь я ничего не пытаюсь решить, просто поймите причину самого поведения.

4.2BSD представил системный вызов rename () с целью разрешить атомарное переименование / перемещение файлов. Из 4.3BSD-Reno / src / sys / ufs / ufs_vnops.c:

 /*
  * If ".." must be changed (ie the directory gets a new
  * parent) then the source directory must not be in the
  * directory heirarchy above the target, as this would
  * orphan everything below the source directory. Also
  * the user must have write permission in the source so
  * as to be able to change "..". We must repeat the call 
  * to namei, as the parent directory is unlocked by the
  * call to checkpath().
  */

 if (oldparent != dp->i_number)
  newparent = dp->i_number;
 if (doingdirectory && newparent) {
  VOP_LOCK(fndp->ni_vp);
  error = ufs_access(fndp->ni_vp, VWRITE, tndp->ni_cred);
  VOP_UNLOCK(fndp->ni_vp);

Так ясно, что эта проверка была добавлена ​​намеренно. Мой вопрос - почему? Это поведение должно быть интуитивно понятным?

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

% cd /tmp
% mkdir stackoverflow-question
% cd stackoverflow-question
% mkdir directory-1
% mkdir directory-2
% mkdir directory-1/directory-i-cant-write
% echo "foo" > directory-1/directory-i-cant-write/contents
% chmod 000 directory-1/directory-i-cant-write/contents
% chmod 000 directory-1/directory-i-cant-write
% mv directory-1/directory-i-cant-write directory-2
mv: rename directory-1/directory-i-cant-write to directory-2/directory-i-cant-write: Permission denied

Теперь у нас есть каталог, который я не могу написать с содержимым, которое я не могу прочитать, что я не могу двигаться атомарно. Однако я могу добиться того же эффекта не атомарно, изменив разрешения, создав новый каталог, используя ln для создания новых ссылок и изменив разрешения. (Оставлено как упражнение для читателя)

. и ... уже в специальном корпусе, поэтому я не особо согласен с тем, что интуитивно понятно, что если я не могу написать каталог, я не могу "изменить ...", что и предполагает источник. Есть ли какая-то причина для этого, кроме того, что автор кода воспринимает правильное поведение? Может ли случиться что-то плохое, если мы позволим людям атомарно перемещать каталоги (которые они не могут писать) между каталогами, которые они могут писать?

Ответы [ 3 ]

2 голосов
/ 06 апреля 2010

Я думаю, вполне вероятно, что Эндрю МакГрегор прав. Не обязательно, что UFS имеет для работы таким образом, но чтобы разработчик (Кирк МакКусик) просто расширил логику разрешений файловой системы, чтобы охватить этот случай. Таким образом, если у вас нет разрешения на запись в целевой каталог, вы не сможете изменить его запись "..".

Но, глядя на ваш пример, пришла еще одна возможность. Может показаться, что проблема не в том, как вы показываете, когда одному пользователю принадлежат все эти каталоги, а в том, что каталоги принадлежат разным пользователям. Другими словами, эта проверка не позволяет мне перемещать ваш каталог между родительскими каталогами, на которые у меня есть разрешение на запись. Предполагая, конечно, что вы не дали мне разрешения на запись в вашем каталоге.

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

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

0 голосов
/ 01 апреля 2010

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

Иногда необходимо ссылаться на файл по имени, например, если должна выполняться программа, которая принимает имя файла в качестве аргумента. Если проверка должна быть выполнена первой, это может привести к опасному состоянию гонки, если для непривилегированного пользователя возможно переименовать любую часть имени пути между временем проверки и временем использования. Иногда это решается путем требования, чтобы каталог, содержащий каждый указанный компонент пути, не имел разрешения на запись для непривилегированных пользователей, гарантируя, что ни один компонент пути не может быть переименован (или не связан, и повторно создан) непривилегированным пользователем в течение этого времени для ссылки на что-то отличное от того, что был проверен. Если непривилегированный пользователь может изменить то, на что ссылается «..», даже без разрешения на запись в этот каталог, это создаст дыру в безопасности. Если бы это было специальное исключение, разрешенное ядром, каждая программа, выполняющая такую ​​проверку, должна была бы специально проверять наличие компонента "..", чтобы избежать этой проблемы.

Кроме того, обновление «..» в каталоге требует записи в блоки данных для этого каталога, а также обновит время последнего изменения каталога, по крайней мере, в традиционных файловых системах Unix и BSD (я знаю, что это не чехол для Apple HFS +, где ".." синтезируется). Кажется интуитивно понятным, что отключение разрешения на запись для других пользователей запретило бы им любую операцию, которая будет выполнять запись в каталог или изменять время последнего изменения.

0 голосов
/ 31 марта 2010

Also the user must have write permission in the source so as to be able to change "..".

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

...