Re: [Vserver] Screen inside vserver

From: Herbert Poetzl <herbert_at_13thfloor.at>
Date: Sat 14 Jan 2006 - 18:22:58 GMT
Message-ID: <20060114182258.GA29461@MAIL.13thfloor.at>

On Sat, Jan 14, 2006 at 11:48:56AM -0600, Michael S. Zick wrote:
> On Sat January 14 2006 11:20, Benedikt Boehm wrote:
> > On Saturday 14 January 2006 17:34, Michael S. Zick wrote:
> > > Using: strace -o screen.txt -e trace=file screen (from within an
> > > xterm)...

> > > These are the system calls (in the guest) that you have to make
> > > succeed from the host that is running udev (the pts/1 is because
> > > the xterm is using pts/0):

> > > - - - -
> > > readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 10
> > > - - - -
> > > readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10
> > > stat64("/dev/pts/1", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...})
> > > = 0 open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3
> > > - - - -

> > > So a simple hardlink might not work, but having a rule
> > > script that also (on the host) makes the correct node in
> > > /<vservers>/<guestroot>/dev/pts/* should work.

> > you're not supposed to make device nodes in /dev/pts, because it is
> > a dynamic filesystem showing allocated pseudo terminals... [1]

> > > Note that it is the stat64 ... st_rdev=makedev(136, 1) that is the
> > > call to the udev system, in your case, triggered on the guest and
> > > but directed at the host.

> > > So the question remains: Which VServer (by host path) and which
> > > xid?

> > > It can't be the /proc/self/<anything> read by the script, since
> > > that is running on the host - not in the guest context that
> > > triggered the request for a pts.

> > > Still scratching my head over this question - it might require a
> > > pre-loaded *.so in the guest context to trap these trigger events
> > > and proxy them to the udev system running in the host context
> > > (with the additional info required).

> > > I just hope someone can suggest an easier way. A good starting
> > > point would be to repeat my tests, since they may have cockpit
> > > errors.

> > Well, prefering fixes and not workarounds (as stated previously ;)
> > i'd rather tend to create the necessary files in /dev/pts (inside
> > the guest) by allocating a pseudo terminal after migrating the
> > vserver process.. trying it out right now, and will report any issue
> > back here..

let me first explain _why_ this happens and _what_
actually happens, so that you can talk about solutions
regarding the issue instead of voodoo :)

I assume you ssh-ed to your host somehow, which
established a pseudo terminal to work as logon terminal
and which is your 'current' connection to the outside

you can verify that with the following commands:

 # ls -la /proc/self/fd/{0,1}
   lrwx------ 1 root root 64 2006-01-14 20:02 /proc/self/fd/0 -> /dev/pts/0
   lrwx------ 1 root root 64 2006-01-14 20:02 /proc/self/fd/1 -> /dev/pts/0

now, this pseudo terminal was allocated via the /dev/ptmx
terminal multiplexor, which 'assigned' the /dev/pts/0
to the host context (i.e. it is tagged as being a host
terminal for linux-vserver)

now you enter the guest via:

 # vserver test101 enter

which does not change anything on the file descriptors
or terminal allocations ... (i.e. the ls from above will
give the exactly same results) but, the following command:

 # ls /dev/pts/
   1

clearly shows that there is no /dev/pts/0 anymore. why?

simple, because the /dev/pts (which is a virtual filesystem
called devpts -- what a name!) is isolated in regard of
contexts, on the host, the same command will show:
 
 # ls /dev/pts/
   0

so, this kind of isolation ensures that the guests will
not read from other guests pseudo terminals and/or send
strange commands to the other end ...

so, the 'real' issue/question is, how to 'reconnect' the
ssh (or whatever) you used to reach the host, with a
new pseude terminal inside the guest in a secure way ...

HTC,
Herbert

PS: a simple but suprisingly natural solution is to
start the screen on the host, right _before_ the enter
(which will work quite fine)

> The main issue is that the /dev/pts is a kernel provided, virtual
> filesystem that tracks which of the 255 pts are in use.

> However you do it, you have to run through the kernel in context 0 so
> that its record keeping is correct.

> Otherwise, you might end up using pts/0 in all of the guests while the
> kernel records that pts/0, pts/1, pts/2 ... are in use.

> I am pretty sure that the kernel will believe any major/minor number a
> device special node carries - so even though the kernel is assigning
> a new /dev/pts/16 to the most recent request - hand creating a
> /vserver/vps16/dev/pts/16 should work since it has the correct
> major/minor. Programs within the guest (such as login) that check
> for a link outside of /dev/* will only see the guest's view of
> /dev/pts/16.

> I am not suggesting that one should modify /dev/pts/* - only the
> /vserver/vps16/dev/pts/16 path. The trick is keeping it in lock-step
> with the kernel's virtual filesystem.
>
> Mike
>
>
> > [1] http://www.nsa.gov/selinux/papers/slinux/node60.html
> > _______________________________________________
> > Vserver mailing list
> > Vserver@list.linux-vserver.org
> > http://list.linux-vserver.org/mailman/listinfo/vserver
> >
> >
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Sat Jan 14 18:23:15 2006

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sat 14 Jan 2006 - 18:23:18 GMT by hypermail 2.1.8