chown не устанавливает SGID

Я пытаюсь создать каталог с разрешениями 02770, чтобы результирующие разрешения были drwxrws---

Когда я запускаю следующие команды, я получаю ожидаемое поведение

rsam.svtest2.serendipity> (/home/svtest2)
$ mkdir abc


rsam.svtest2.serendipity> (/home/svtest2)
$ ls -lrt
drwxrwxr-x  2 svtest2 users    6 Apr 18 10:57 abc

rsam.svtest2.serendipity> (/home/svtest2)
$ chmod 02770 abc

rsam.svtest2.serendipity> (/home/svtest2)
$ ls -lrt
drwxrws---  2 svtest2 users    6 Apr 18 10:57 abc

ОБНОВЛЕНИЕ #1 Исходя из вышеизложенного, после запуска mkdir и chmod в каталоге, когда я запускаю chown, бит SGID сбрасывается.

rsam.svtest2.serendipity> (/home/svtest2)
$ chown svtest2:users abc



rsam.svtest2.serendipity> (/home/svtest2)
$ ls -lrt
drwxrwx---  2 svtest2 users    6 Apr 18 10:57 abc

Из документации Chown,

Только привилегированный процесс (Linux: один с возможностью CAP_CHOWN) может изменить владельца файла. Владелец файла может изменить группу файла на любую группу, членом которой является этот владелец. Привилегированный процесс (Linux: с CAP_CHOWN) может произвольно изменить группу.

Проблема в том, что мой пользователь svtest не имеет возможности CAP_CHOWN. Теперь вопрос сводится к тому, как заставить пользователя иметь возможность CAP_CHOWN?

Похоже, здесь есть какая-то инструкция - ТАК - установка CAP_CHOWN, но я еще не попробовал ее.

Однако, когда я запускаю код ниже C++ (часть сервера смокинга)

// Check if the directory exists and if not creates the directory
// with the given permissions.
struct stat st;
int lreturn_code = stat(l_string, &st);



if (lreturn_code != 0 &&
    (mkdir(l_string, lpermission) != 0 ||
     chmod(l_string, lpermission) != 0)) {
     ....
     ....
     }
     ....
     ....
// Convert group name to group id into lgroup
        if (chown(l_string, -1, lgroup) != 0) {
            // System error.
        }

Каталог создается как показано ниже:

$ ls -l|grep DirLevel1
drwxrwx--- 2 svtest2 users         6 Apr 18 11:14 DirLevel1

Обратите внимание, что бит SGUID не устанавливается в отличие от того, когда команды выполнялись напрямую, как указано выше.

Выдержка из операции для операции:

5864  stat("/home/svtest2/data/server/log/DirLevel1/", 0x7ffd235f29f0) = -1       ENOENT (No such file or directory)
5864  mkdir("/home/svtest2/data/server/log/DirLevel1/", 02770) = 0
5864  chmod("/home/svtest2/data/server/log/DirLevel1/", 02770) = 0
5864  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 15
5864  connect(15, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
5864  close(15)                         = 0
5864  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 15
5864  connect(15, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"},  110) = -1 ENOENT (No such file or directory)
5864  close(15)                         = 0
5864  open("/etc/group", O_RDONLY|O_CLOEXEC) = 15
5864  fstat(15, {st_mode=S_IFREG|0644, st_size=652, ...}) = 0
5864  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f414d7c4000
5864  read(15, "root:x:0:\nbin:x:1:\ndaemon:x:2:\ns"..., 4096) = 652
5864  close(15)                         = 0
5864  munmap(0x7f414d7c4000, 4096)      = 0
5864  chown("/home/svtest2/data/server/log/DirLevel1/", 4294967295, 100) = 0
5864  write(7, "\0\0\2~\6\0\0\0\0\0\21i\216\376\377\377\377\377\377\377\377\1\0\0\0\0\0\0\0\1\0\0"..., 638) = 638
5864  read(7, "\0\0\0\300\6\0\0\0\0\0\10\0\0\0\0\250\0\0\0\0\0\0\0\0\0(\0\0\0\0\0\0"..., 8208) = 192
5864  write(7, "\0\0\1}\6\0\0\0\0\0\3h\221\1\0\0\0\0\0\0\0\376\377\377\377\377\377\377\377\250\0\0"..., 381) = 381
5864  read(7, "\0\0\0\26\6\0\0\0\0\0\10\4\0\0\0\t\1\0\0\0\215\f", 8208) = 22
5864  msgsnd(43679799, {805306373, "y\0\0\0007\200\232\2\0\0\0\0\f\2\0\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\0\0"...}, 516, IPC_NOWAIT) = 0
5864  msgrcv(43614264,

С http://man.sourcentral.org/RHEL7/2+chown,

Когда владелец или группа исполняемого файла изменяются непривилегированным пользователем, биты режима S_ISUID и S_ISGID очищаются. POSIX не указывает, должно ли это происходить, когда root выполняет chown(); Поведение Linux зависит от версии ядра. В случае неисполняемого группой файла (то есть файла, для которого не установлен бит S_IXGRP) бит S_ISGID указывает на обязательную блокировку и не очищается с помощью chown().

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

Источник

1 ответ

Поскольку система *nix рассматривает файл как исполняемый файл, видя бит разрешения 'x', я считаю, что каталог с возможностью поиска может также рассматриваться как исполняемый файл.

Источник
Другие вопросы по тегам