descompactar --pasta -map-root-user para o uid / username original após a configuração

5

Estou usando o compartilhamento não compartilhado para criar montagens por processo, o que está funcionando perfeitamente por

unshare -m --map-root-user

No entanto, depois de ter criado minhas montagens de bind por

mount --bind src dst

Eu quero alterar o UID para o meu usuário original, para que whoami (e outros) faça eco do meu nome de usuário como echo $USER .

Eu já tentei a resposta de Simule o chroot com não compartilhamento

No entanto, fazendo su – user1 após chroot / , obtenho

su: Authentication failure
(Ignored)
setgid: Invalid argument

Eu testei isso no Ubuntu 18.04 Beta, extensão Debian, openSUSE-Leap-42.3. É tudo a mesma coisa. Eu acho que algo mudou no kernel desde que esta resposta estava funcionando.

O que é uma maneira correta e funcional de fazer isso (sem ter raiz real )?

    
por spawn 26.04.2018 / 12:46

1 resposta

0

O comando unshare(1) não pode:

-r, --map-root-user
[...] As a mere convenience feature, it does not support more sophisticated use cases, such as mapping multiple ranges of UIDs and GIDs.

Grupos suplementares, se houver algum ( video , ...) serão perdidos de qualquer maneira (ou mapeados para nogroup ).

Ao mudar novamente para um segundo novo namespace de usuário, é possível reverter o mapeamento. Isso requer um programa personalizado, pois unshare(1) não faz isso. Aqui está um programa C muito minimalista como prova de conceito (apenas um usuário: uid / gid 1000/1000, verificação de falha zero). Vamos chamá-lo de revertuid.c :

#define _GNU_SOURCE
#include <sched.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#include <unistd.h>

int main(int argc, char *argv[]) {
    int fd;

    unshare(CLONE_NEWUSER);
    fd=open("/proc/self/setgroups",O_WRONLY);
    write(fd,"deny",4);
    close(fd);
    fd=open("/proc/self/uid_map",O_WRONLY);
    write(fd,"1000 0 1",8);
    close(fd);
    fd=open("/proc/self/gid_map",O_WRONLY);
    write(fd,"1000 0 1",8);
    close(fd);
    execvp(argv[1],argv+1);
}

Está apenas fazendo o mapeamento reverso do mapeamento feito por unshare -r -m , que era inevitável, para poder ser root e usar mount , como visto em:

$ strace unshare -r -m /bin/sleep 1 2>&1 |sed -n '/^unshare/,/^execve/p'
unshare(CLONE_NEWNS|CLONE_NEWUSER)      = 0
open("/proc/self/setgroups", O_WRONLY)  = 3
write(3, "deny", 4)                     = 4
close(3)                                = 0
open("/proc/self/uid_map", O_WRONLY)    = 3
write(3, "0 1000 1", 8)                 = 8
close(3)                                = 0
open("/proc/self/gid_map", O_WRONLY)    = 3
write(3, "0 1000 1", 8)                 = 8
close(3)                                = 0
execve("/bin/sleep", ["/bin/sleep", "1"], [/* 18 vars */]) = 0

Então isso dá:

user@stretch-amd64:~$ gcc -o revertuid revertuid.c
user@stretch-amd64:~$ mkdir -p /tmp/src /tmp/dst
user@stretch-amd64:~$ touch /tmp/src/file
user@stretch-amd64:~$ ls /tmp/dst
user@stretch-amd64:~$ id
uid=1000(user) gid=1000(user) groups=1000(user)
user@stretch-amd64:~$ unshare -r -m
root@stretch-amd64:~# mount --bind /tmp/src /tmp/dst
root@stretch-amd64:~# ls /tmp/dst
file
root@stretch-amd64:~# exec ./revertuid bash
user@stretch-amd64:~$ ls /tmp/dst
file
user@stretch-amd64:~$ id
uid=1000(user) gid=1000(user) groups=1000(user)

Ou mais curto:

user@stretch-amd64:~$ unshare -r -m sh -c 'mount --bind /tmp/src /tmp/dst; exec ./revertuid bash'
user@stretch-amd64:~$ ls /tmp/dst
file

O comportamento provavelmente mudou após o kernel 3.19, como visto em user_namespaces(7) :

The /proc/[pid]/setgroups file was added in Linux 3.19, but was backported to many earlier stable kernel series, because it addresses a security issue. The issue concerned files with permissions such as "rwx---rwx".

    
por 20.07.2018 / 13:11