2016-04-18 7 views
1

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

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

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 

UPDATE # 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 documentation,

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

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

Похоже, здесь есть инструкция - SO - setting 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().

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

+0

Ожидаемое поведение или ошибка, конечно, обходное решение очень просто: просто вызовите 'chmod' еще раз. –

+0

В Linux все это файл (файл, каталог и т. Д.). Не существует различий, является ли это файлом или каталогом, где 'S_IXGRP' не установлен. Он либо установлен, либо нет. Похоже, что применяется предложение 1, и вы, как непривилегированный пользователь, пытаетесь создать новый файл в каталоге set_gid (и, таким образом, измените свою группу в соответствии с битом 'S_ISGID' в родительском каталоге), который имеет эффект очистки битов , Это мое чтение. Попробуйте запустить с правами root и посмотрите, разрешены ли права. –

+0

Я попытался запустить chown как root, так как да разрешения остаются как есть (обновленный вопрос выше). Я не смог добавить возможности CAP_CHOWN для не-привилегированного пользователя. – Phalgun

ответ

0

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

+0

Sheesh ... С помощью каталога 'x' controls * спускаются в * разрешение. Таким образом, бит 'x' на * user *, * group * или * world * определяет, может ли * user *, * group * или * world * спуститься (то есть прочитать содержимое) каталога. –