|
Bugzilla – Full Text Bug Listing |
| Summary: | VNC - persistent session is not possible - "wait = yes" is not working | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Petr Vodicka <vodicka.petr> |
| Component: | X11 Applications | Assignee: | Reinhard Max <max> |
| Status: | RESOLVED WONTFIX | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Major | ||
| Priority: | P5 - None | Flags: | coolo:
SHIP_STOPPER-
|
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.0 | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
This is part of my xinetd.log: 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) 08/5/14@21:52:06: START: vnc2 from=<no address> 08/5/14@21:52:06: EXIT: vnc2 signal=13 duration=0(sec) *** This bug has been marked as a duplicate of bug 385677 *** Bug is not solved. I have upgraded OpenSUSE 11 to RC1 and then to Factory version and still same bahaviour. Only xinetd.log changed slightly. 08/5/31@12:56:46: START: vnc2 from=<no address> 08/5/31@12:56:47: EXIT: vnc2 status=0 duration=1(sec) 08/5/31@12:56:47: START: vnc2 from=<no address> 08/5/31@12:56:47: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:47: START: vnc2 from=<no address> 08/5/31@12:56:47: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:47: START: vnc2 from=<no address> 08/5/31@12:56:47: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:47: START: vnc2 from=<no address> 08/5/31@12:56:47: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:47: START: vnc2 from=<no address> 08/5/31@12:56:48: EXIT: vnc2 status=0 duration=1(sec) 08/5/31@12:56:48: START: vnc2 from=<no address> 08/5/31@12:56:48: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:48: START: vnc2 from=<no address> 08/5/31@12:56:48: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:48: START: vnc2 from=<no address> 08/5/31@12:56:48: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:48: START: vnc2 from=<no address> 08/5/31@12:56:48: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:48: START: vnc2 from=<no address> 08/5/31@12:56:48: EXIT: vnc2 status=0 duration=0(sec) 08/5/31@12:56:48: START: vnc2 from=<no address> 08/5/31@12:56:49: EXIT: vnc2 status=0 duration=1(sec) Indeed I can reproduce this issue with RC1. Reinhard, can you investigate? 10.3 and 11.0 use entirely different implementations for Xvnc. The one in 10.3 contains code to make it work with wait=yes, the one in 11.0 does not. I think supporting wait=yes would defeat the purpose of the -inetd switch to allow an arbitrary number of on-the-fly generated one-shot vnc sessions. It would even be a security risk, because vnc sessions created through xinetd are not password protected. A user who disconnects from such a session without explicitly locking it at the X level would leave it open for an attacker. You can use the vncserver script from the tightvnc package or call Xvnc directly to start persistent vnc sessions that are independent of xinetd. :( Easy way how to solve bug... I don't agree with you. Connection to vnc can be easily secured with password. Just rfbauth argument must be added. So I dont think that it's security risk. If I use tightvnc script It only starts plain X with xterm in default, so use xinetd was the easiest way how to start Xvnc with KDE running. Yes, I can change xstartup script to start xinitrc script, but it's not easy to find this solution on internet. (In reply to comment #7 from Petr Vodicka) > :( Easy way how to solve bug... It's not a bug, it's just a (from our side) unintended feature that is gone again, but we are open for patches to re-add it. > Connection to vnc can be easily secured with password. > Just rfbauth argument must be added. So I dont think that it's security risk. Right, I oversaw that part. OTOH, that would have to be a per-system VNC password, while normally VNC passwords are per user. And still, doing this all would defeat the purpose of the whole xinetd based setup. > If I use tightvnc script It only starts plain X with xterm in default, so use > xinetd was the easiest way how to start Xvnc with KDE running. Yes, I can > change xstartup script to start xinitrc script, but it's not easy to find this > solution on internet. You can also just start Xvnc by hand and use the -query option to get a persistent session with KDM login screen: Xvnc :1 -query localhost (In reply to comment #8 from Reinhard Max) > (In reply to comment #7 from Petr Vodicka) > > :( Easy way how to solve bug... > > It's not a bug, it's just a (from our side) unintended feature that is gone > again, but we are open for patches to re-add it. > Sorry, I was looking on that from wrong side. I appreciate your work you made for us. > > Connection to vnc can be easily secured with password. > > Just rfbauth argument must be added. So I dont think that it's security risk. > > Right, I oversaw that part. OTOH, that would have to be a per-system VNC > password, while normally VNC passwords are per user. And still, doing this all > would defeat the purpose of the whole xinetd based setup. > You are right. Per-user password is not secure enough. > > If I use tightvnc script It only starts plain X with xterm in default, so use > > xinetd was the easiest way how to start Xvnc with KDE running. Yes, I can > > change xstartup script to start xinitrc script, but it's not easy to find this > > solution on internet. > > You can also just start Xvnc by hand and use the -query option to get a > persistent session with KDM login screen: > > Xvnc :1 -query localhost > Thank you for your advice. It's so easy, but I was unable to find it. |
Hi, I want to connect to my OpenSUSE 11 pc via VNC, but I need to leave session opened after disconnect. This can be done with "wait = yes" argument in xinetd vnc configuration (/etc/xinet.d/vnc) and it's working in OpenSUSE 10.3, but not in OpenSUSE 11. Client just creates connection on TCP/IP (only 3 packets visible in Wireshark) and then nothing is happening on client side, just waiting. But on server side is happening something weird. Xvnc process starts, but dies immediately and another starts again. This is happening hundreds times per second. This is my configuration: service vnc2 { socket_type = stream protocol = tcp wait = yes user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16 type = UNLISTED port = 5902 } If I change "wait = yes" to "wait = no", connection is working, but persistent session not (as it should with this configuration). Than you for your time, Petr