Open Parakleta opened 2 years ago
Thanks for reporting. Do you think this is a regression? I.e. is there a LibVNCServer version that worked before?
This is definitely a regression. This use case (unix sockets) worked in the 0.9.13 source tarball download from sourceforge, and in the distros that based off that.
I cannot find this code in any repository however, just in the source tarball, so I’m not sure what has happened with it or what exactly it came from.
@Parakleta wait, you're talking about x11vnc or libvncserver?
Both. There is functionality documented in x11vnc which doesn’t work due to code missing from libvncserver.
There is no reasonable way that I can see to fix the issue in x11vnc because it relies on information that libvncserver doesn’t collect or provide, so this has to be resolved here by integrating somehow the code sample I provide from 0.9.13.
Ah so you mean x11vnc 0.9.13 and not LibVNCServer 0.9.13? I propose you simply file a pull request and we can discuss there or if the code was in LibVNCServer but is now broken, flag the commit that caused the change so we can revert/change.
The relevant code is in the file I linked above but unfortunately I cannot flag the relevant commit because the code was never in this fork and I cannot find a commit for it in the sourceforge repository either. The only copy of it I can find is in the tarball.
Ideally if you can find the person who made the 0.9.13 tarball and get a copy of their (possibly) unpublished repository you may be able to cherrypick the commits onwards from 0.9.12 and try to rebase them on top this repo. Failing that you’ll probably need to rebase this repo on top of the 0.9.13 code and diff it against HEAD to generate a patch which can replace the missing functionality (which would then be applied against the current HEAD).
Both of these tasks are way to complex and dangerous for me to undertake with my lack of knowledge of the design and history of this project.
TBH, I'm a bit confused as the LibVNCServer and x11vnc version numbers are somewhat close by. Are you referring to 0.9.12 and 0.9.13 libvncserver or x11vnc?
Is the point you're making maybe that there's an older x11vnc release that had it's own internal copy of libvncserver and this deviates from this here repository regarding the Unix sockets support?
Is the point you're making maybe that there's an older x11vnc release that had it's own internal copy of libvncserver and this deviates from this here repository regarding the Unix sockets support?
Exactly this.
This issue presents itself in x11vnc, but is caused by a deviation between this project and 0.9.13 of the original project.
Specifically, running
x11vnc -display :0 -rfbport 0 -unixsock /tmp/sock
launches without a problem, but every attempt to connect using a client is rejected with the following error:The relevant code is in
rfbNewTCPOrUDPClient
. Specifically, after https://github.com/LibVNC/libvncserver/blob/2499602e7a975fa2882af4a65962a85963950991/libvncserver/rfbserver.c#L334 the following code appears instead:The specific feature difference of this code is that it always sets
cl->host
so some value (except in the case ofisUDP
, not sure what the path is supposed to be there?). This is important because the callbackcl->screen->newClientHook(cl)
later in this same method does the access check that fails as shown above.Curiously there is a bit of code in the x11vnc project under
check_unix_sock()
which updates the value ofcl->host
but this occurs only after thecheck_access
method has already failed, and I cannot see any historical version of this project where that would have ever worked.