Почему обычный пользователь не может удалить btrfs подобъем

Хорошо это было полезным опытом для меня, но я в конечном счете понял это. Я объясню свой процесс здесь так, чтобы было легче знать, как понять этот материал самостоятельно (документация BTRFS, поскольку я уверен, что Вы узнали, является относительно неполным в настоящее время).

Сначала я думал, что создание подобъема было ioctl с обработчиком, который не сделал никакой проверки возможности (который может или не мог быть проблемой безопасности в зависимости от того, была ли некоторая логика к ней), тогда как удаление ее изменяло метаданные непосредственно (и таким образом пользователь мог бы потребовать CAP_SYS_RAWIO работать правильно).

Для проверки я взломал btrfs-utils исходный код и это - то, что я нашел:

Create subvolume, cmds-receive.c Line 180:
         ret = ioctl(r->dest_dir_fd, BTRFS_IOC_SUBVOL_CREATE, &args_v1);

Delete subvolume, cmds-subvolume.c Line 259:
         res = ioctl(fd, BTRFS_IOC_SNAP_DESTROY, &args);

Ну, это не полезно, они - оба ioctl's (интересное примечание стороны: "снимок" часто используется interchangably в исходном коде с "подобъемом" по некоторым причинам). Таким образом, я перешел к исходному коду ядра и нашел оба обработчика в fs/btrfs/ioctl.c.

В конечном счете я проследил его до btrfs_ioctl_snap_destroy() и на строке 2116:

     if (!capable(CAP_SYS_ADMIN)){

А именно, это - проверка, если у них нет возможности, но если у них действительно есть она, логика пропускает прямо к выполнению операции. Тело, если проверки оператора, чтобы видеть, является ли это обычный пользователь, который является владельцем inode подобъема и USER_SUBVOL_RM_ALLOWED Опция BTRFS, включают его, продолжает выполнять обработчик. Если у них нет ни одного, из которого ioctl обработчик выходит с ошибкой.

Таким образом, похоже, что уничтожение "снимка" (иначе "подобъем") обычно требует пользователя, который имеет CAP_SYS_ADMIN (или для USER_SUBVOL_RM_ALLOWED чтобы быть включенным и пользователь "владеет" данным подобъемом). Большой, что относительно того, чтобы создать снимок/объем?

Обработчик для ioctl, кажется, btrfs_ioctl_snap_create() этот обработчик, кажется, не содержит вызова к capable() прямо или косвенно. Так как это - основной способ, которым поддержан доступ, я беру это, чтобы означать, что создание подобъема всегда успешно выполняется. Это объясняет на функциональном уровне, почему Вы видите, что Вы видите.

Я не могу говорить с тем, почему это считают желательным за пределами основного варианта использования BTRFS, являющегося с сервером с ограниченным пользовательским доступом. Это не достаточно, но я не вижу кода для фактической остановки операции. Если Вы не можете найти ответ на то, почему это (и Вы хотите иметь его), Вам, вероятно, придется спросить относительно списка рассылки ядра.

Заключение

Мое исследование, кажется, указывает, что любой может создать подобъемы, но для удаления подобъема, который Вы любой должны иметь CAP_SYS_ADMIN или этому нужно верный и что вызывающий абонент является владельцем подобъема inode и USER_SUBVOL_RM_ALLOWED включенный.

Создание подобъема не имеет смысла, таким образом, я, вероятно, пропускаю некоторый косвенный способ, которым отклонена операция, так как это походит на простой способ к DoS система.

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