Jexec and access to tty

[joris dedieu]

2011/8/9 Paul Schenkeveld <freebsd at psconsult.nl>:
> Hi,
>
> There have been several threads about this issue, some people have come
> up with work arounds but I think that the issue is more fundamental,
> that's why I wanted to start this new thread.
>
> When using jexec to do interactive work inside an existing jail, people
> find out that they no longer have access to their tty device.  As a
> result, programs requiring input of passwords or passphrases behave
> unexpectedly in one of several ways.
>
> Ssh says "Host key verification failed." and refuses to log in to
> another system (unless pubkey authentication is user in combination with
> an agent of course).  Some programs fall back to using stdin/stdout
> and echo the password as it is typed (the mysql clients are popular
> examples).
>
> Work-arounds that have been suggested are
>  1. Run a sshd inside the jail and log in using ssh
>  2. Start tmux inside the jail so you get a new pseudo tty slave inside
>    the jail.  People trying screen find that it won't work unlike tmux.
>  3. I tried using 'script -q /dev/null' inside the jail because it is
>    part op the base system and it doesn't change your terminal type
>    and interpret keyboard input and screen output.  I found out that I
>    failed when I resized my window :-(

An other way is to use chroot(5) to enter the jail.
Maybe chroot /jail/root login -f $USER should be acceptable in some situations.

>
> I don't like 1 on a machine with many jails, especially if some of them
> share the same IP address (e.g. sometimes I have to run a mail server on
> the same IP adress as a webserver but in a distinct jail).
>
> 2 is not ideal either because tmux emulates a different terminal on
> the inside than the terminal on the outside that it runs on.
>
> 3 is really a kludge and causes problems when you resize your window.
>
> I thought that I found a solution by rewriting jexec such that it will
> open a pseudo tty and does the passing of data between the jailed pts
> and the tty from where jexec was started but that's not going to work as
> the pseudo tty most be opened by the child process inside the jail but
> the parent outside the jail must have access to the master side of the
> pseudo tty.
>
> So far we are still talking about work-arounds.  Why not look at the
> root cause.  Unfortunately I'm not familiar with kernel sources so if
> I'm wrong, please forgive me, I write this with the best intentions.
>
> The root cause of th problem appears to be that pseudo ttys opened
> outside a jail are not visible nor accessible inside a jail, pseudo ttys
> created inside a jail are visible and accessible though.

As far as I understand, sys/fs/devfs/devfs_vnops.c uses
prison_check(9) too see if an item as been build in the same jail or
in a child.
The tty exists inside the jail but you can't use it (and so you can't
escape the jail).

>
> Would it be conceivable that by using jexec the controlling tty of jexec
> magically becomes visible and accessible inside the jail?  Preferrable
> only until jexec dies.

I'm not sure. The only way should be  to temporary disable the check
with a  variable. But it will also brake jail security during jexec
excution.
Using chroot(2) instead of jail(2) should be an option (but it's  non
trivial to affect jail context for all other subsystems).

I think the only right way is to open a new tty while entering the
jail (this is what tmux or a jailed ssh does).
But it should be difficult to make things like echo ps | jexec 1 sh works.

regards
Joris

>
> I understand that this is not trivial but given the number of threads
> about this problem, it's a real issue to many people.  To me it's worth
> some $ or EUR to solve this in a clean way.
>
> Kind regards,
>
> Paul Schenkeveld
> _______________________________________________
> freebsd-jail at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "freebsd-jail-unsubscribe at freebsd.org"
>