Date: Wed, 10 Aug 2011 14:49:29 +0200 From: joris dedieu <joris.dedieu@gmail.com> To: Paul Schenkeveld <freebsd@psconsult.nl> Cc: freebsd-jail@freebsd.org Subject: Re: Jexec and access to tty Message-ID: <CAPd55qBGAkQDxQ6cy7=M%2BxxX%2BHnAoR%2B8_iCS6QMxxSi-iNnniA@mail.gmail.com> In-Reply-To: <20110809124543.GA22077@psconsult.nl> References: <20110809124543.GA22077@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/8/9 Paul Schenkeveld <freebsd@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. =A0As 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). =A0Some 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 > =A01. Run a sshd inside the jail and log in using ssh > =A02. Start tmux inside the jail so you get a new pseudo tty slave inside > =A0 =A0the jail. =A0People trying screen find that it won't work unlike t= mux. > =A03. I tried using 'script -q /dev/null' inside the jail because it is > =A0 =A0part op the base system and it doesn't change your terminal type > =A0 =A0and interpret keyboard input and screen output. =A0I found out tha= t I > =A0 =A0failed 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 situati= ons. > > 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. =A0Why not look at the > root cause. =A0Unfortunately 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? =A0Preferrable > 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. =A0To me it's worth > some $ or EUR to solve this in a clean way. > > Kind regards, > > Paul Schenkeveld > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPd55qBGAkQDxQ6cy7=M%2BxxX%2BHnAoR%2B8_iCS6QMxxSi-iNnniA>