On Fr, 29.06.18 21:24, Nikolaus Rath (nikol...@rath.org) wrote:

> >> The 'nsenter' approach seems to work so far, but I don't see a generally
> >> applicable way to figure out the right PID. Is there a trick for
> >> that?
> >
> > machinectl show --value $MACHINE -p Leader
> 
> Still not quite working, now there seems to be a problem with
> /proc/self/fd in the new shell:
> 
> $ sudo systemd-nspawn -M $MACHINE \
>      --private-users=1379532800:65536 --private-network \
>      --as-pid2
> 
> # Other terminal
> 
> $ pid=$(machinectl show --value $MACHINE -p Leader 2> /dev/null)
> $ sudo nsenter -t ${pid} --mount --uts --ipc --net --pid --cgroup --user
> [root@iofabric /]# echo $UID
> 0
> [root@iofabric /]# echo 1 > /dev/stderr 
> -bash: /dev/stderr: Permission denied
> [root@iofabric /]# ll /dev/stderr
> lrwxrwxrwx 1 root root 15 Jun 29 21:13 /dev/stderr -> /proc/self/fd/2
> [root@iofabric /]# ll /proc/self/fd/2
> lrwx------ 1 root root 64 Jun 29 21:22 /proc/self/fd/2 -> /dev/pts/0
> [root@iofabric /]# ll /dev/pts/
> total 0
> crw-rw-rw- 1 root root 5, 2 Jun 29 21:13 ptmx
> [root@iofabric /]# 
> 
> 
> What's happening here?

the stdin/stdout/stderr fds of the nsenter process reference pipes
that belong to the host side, and the kernel doesn't allow them to be
reopened if user namespacing is used, for security reasons.

"systemd-run -M $MACHINE -t /bin/sh" should generally be the better
choice than "nsenter", as it will instantiate a shell originating
inside the container and will allocate a pty for it that it will proxy
to the caller's TTYs. This means you get much safer and correct
behaviour as the container will only run container code and the host
only host code, and the connection between them is limited to the pty
transport between them. Since the pty is allocated in the container
/dev/stderr and friends should work fine.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to