ошибка сообщения о гранте после удаления

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

uid before unshare:5000
uid after unshare:0
Grant pt Error: : Permission denied

Код:

#define _GNU_SOURCE

#include <sys/mount.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <sched.h>

void set_uid_map(pid_t pid, int inside_id, int outside_id, int length) {
    char path[256];
    sprintf(path, "/proc/%d/uid_map", getpid());
    FILE* uid_map = fopen(path, "w");
    fprintf(uid_map, "%d %d %d", inside_id, outside_id, length);
    fclose(uid_map);
}
void set_gid_map(pid_t pid, int inside_id, int outside_id, int length) {
    char path[256];
    sprintf(path, "/proc/%d/gid_map", getpid());
    FILE* gid_map = fopen(path, "w");
    fprintf(gid_map, "%d %d %d", inside_id, outside_id, length);
    fclose(gid_map);
}

int main(void)
{
int master;
int flag = 0;

 flag |= CLONE_NEWUSER;
 flag |= CLONE_NEWNS;
 flag |= CLONE_NEWIPC;
 flag |= CLONE_NEWNET;
 flag |= CLONE_NEWUTS;
 flag |= CLONE_NEWPID;

 printf("uid before unshare:%d \n", (int) getuid());
 unshare(flag);

 set_uid_map(getpid(), 0, 5000, 1);
 set_gid_map(getpid(), 0, 5000, 1);

 printf("uid after unshare:%d \n", (int) getuid());

 if ( ( master = posix_openpt(O_RDWR | O_NOCTTY) ) < 0)
      perror("Openpt Error: ");
 if ( grantpt(master) < 0 )
      perror("Grant pt Error: ");
 unlockpt(master);


return 0;
} // main

Если я удалю flag |= CLONE_NEWUSER;, об ошибке не будет сообщено. Можете ли вы помочь объяснить, почему это происходит? заранее спасибо!


person Sven    schedule 21.07.2015    source источник


Ответы (1)


Поскольку у меня была такая же проблема, я также изучил это. Вот мои выводы:

grantpt(3) пытается убедиться, что подчиненный псевдотерминал имеет группу, установленную в специальную группу tty (или любую другую группу TTY_GROUP при компиляции glibc):

static int tty_gid = -1;
if (__glibc_unlikely (tty_gid == -1))
  {
    char *grtmpbuf;
    struct group grbuf;
    size_t grbuflen = __sysconf (_SC_GETGR_R_SIZE_MAX);
    struct group *p;

    /* Get the group ID of the special `tty' group.  */
    if (grbuflen == (size_t) -1L)
      /* `sysconf' does not support _SC_GETGR_R_SIZE_MAX.
         Try a moderate value.  */
      grbuflen = 1024;
    grtmpbuf = (char *) __alloca (grbuflen);
    __getgrnam_r (TTY_GROUP, &grbuf, grtmpbuf, grbuflen, &p);
    if (p != NULL)
      tty_gid = p->gr_gid;
  }
gid_t gid = tty_gid == -1 ? __getgid () : tty_gid;

/* Make sure the group of the device is that special group.  */
if (st.st_gid != gid)
  {
    if (__chown (buf, uid, gid) < 0)
      goto helper;
  }

См. https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/grantpt.c;h=c04c85d450f9296efa506121bcee022afda3e2dd;hb=HEAD#l137.

В моей системе группа tty равна 5. Однако эта группа не сопоставлена ​​с вашим пространством имен пользователя, и chown(2) не работает, поскольку GID 5 не существует. Затем glibc возвращается к выполнению помощника pt_chown, что также не удается. Я не вникал в детали того, почему он терпит неудачу, но я предполагаю, что это связано с тем, что это setuid Nobody, если вы не сопоставили пользователя root с вашим пространством имен пользователя. Вот вывод strace, показывающий неудачную операцию:

[pid    30] chown("/dev/pts/36", 1000, 5) = -1 EINVAL (Invalid argument)

Это дает вам несколько способов обойти эту проблему:

  • Сопоставьте необходимые группы (например, tty), что может быть невозможно без CAP_SYS_ADMIN в двоичном файле, открывающем пространство имен пользователя.
  • Используйте subuids и subgid вместе с newuidmap(1) и newgidmap(1), чтобы сделать эти группы доступными (это может сработать, но я не проверял).
  • Внесите изменения, чтобы избежать сбоя вызова chown(2), например. используя пространство имен монтирования и изменив GID группы tty в /etc/groups на GID вашего пользователя.
  • Избегайте вызова chown(2), например. сделав проверку st.st_gid != gid ложной; это должно быть возможно путем удаления группы tty из целевого пространства имен монтирования /etc/groups. Конечно, это может вызвать другие проблемы.
person neverpanic    schedule 23.07.2015