[winswitch] detecting an attempt by an app to open a window

Tue Nov 1 10:33:53 GMT 2016

On 31/10/16 23:12, Mukul Agrawal wrote:
> Thanks Antoine.
> 
> Basically, I want to detect if user's app want to generate a graphical
> output and then I like to automatically connect user to the xpra html5
> client. I would like to be able to capture any window creation request
> whether client uses x11 API, openGL or anything else.
> At this point of time, I am not worried about video, sound, mouse or
> keyboard --- graphics window is the only thing that I care about.
The XCreateWindow is what you are looking for, application side.
The X11 server will emit a "CreateNotify" event for each new window.
You can find an example code that prints each CreateNotify event it sees
here:
http://xpra.org/trac/browser/xpra/trunk/src/tests/xpra/x11/bindings/listen_maprequests.py?rev=14372
(requires latest xpra trunk code to be installed)

Cheers
Antoine


>  
> Regards, Mukul ( https://sites.google.com/site/mukulagrawal )
> 
> 
> On Friday, October 28, 2016 10:01 PM, Antoine Martin
> <antoine at nagafix.co.uk> wrote:
> 
> 
> On 29/10/16 04:18, Mukul Agrawal wrote:
>> Following is probably not a xpra specific question rather generic x11
>> question, but I would appreciate if you have any pointers regarding this.
>>
>> I start variety of command-line applications on a headless remote host.
>> I have an xpra server running on this host and I make all applications
>> to send their "potential" graphical outputs to the xpra display. Not all
>> applications will generate graphical output.
>> In cases,  when application does try to open a graphical window on the
>> xpra display, I would like to take some follow-up action. How do I
>> detect that application is trying to send something to the display?
> There are many ways of detecting that applications try "to send
> something to the display", it really depends what "follow-up action" you
> want to trigger and how reliable you want this to be.
> 
> X11 applications will open a connection to the X11 server:
> https://tronche.com/gui/x/xlib/display/opening.html
> but that alone is not a guarantee that they will "show" something (they
> may just interact with the clipboard, keyboard or whatever).
> X11 applications that show windows will need to call XCreateWindow:
> https://linux.die.net/man/3/xcreatewindow
> So that's another way of detecting that they intend to show something
> (but then you have to check that the window is actually mapped, visible
> and displayed, etc)
> Both can be intercepted with LD_PRELOAD tricks.
> 
> Looking at it from the window manager's perspective (xpra, which
> connects to the X11 server as a client), we get notifications from the
> X11 server when any new window is created. That's the core of any window
> manager. Then you need to reconcile this window with the process that
> spawned it:
> http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window
> At that point, you usually also have many other window attributes you
> can use ("WM_CLASS", title, etc).
> 
> Cheers
> Antoine
> 
> 
> 
>> 
>> Regards,
>> Mukul
>> ( https://sites.google.com/site/mukulagrawal
> <https://sites.google.com/site/mukulagrawal>)
>>
>>
>>
>> On Tuesday, October 11, 2016 8:18 PM, Antoine Martin
>> <antoine at nagafix.co.uk <mailto:antoine at nagafix.co.uk>> wrote:
>>
>>
>> On 12/10/16 03:28, Mukul Agrawal wrote:
>>> On Ubuntu Xenial, xpra is using the fallback option of Xvfb.
>>> I will like to somehow be able to use Xdummy.
>>> My specific use-case is on headless machines .... so I don't have any
>>> Xorg starting by default.
>>> Is there any workaround that can enable me to use Xdummy?
>> Possibly, the Xdummy wiki page gives some clues about some of the
>> permission changes that may be required (tested with Trusty):
>> http://xpra.org/trac/wiki/Xdummy#Ubuntu
>>
>>> Is this expected to be a long term problem or do you expect to have a
>>> solution in near term?
>> Until Ubuntu fixes their packages or provides a workaround, no.
>>
>>> I highly doubt Ubuntu will do anything about it, even in near future LTS
>>> releases.
>> You should be asking the Ubuntu developers.
>> They should know since they're the ones patching the upstream Xorg
>> packages. Debian does not have this issue either.
>>
>>> Alternatively, if I rollback to Trusty, do I need to follow the
>>> procedure mentioned in the link below?
>>> Or will newer releases of xpra take care of it automatically?
>> There is nothing we can do in our code: the broken Xorg packaging is
>> Ubuntu's, not ours.
>>
>>> [I never followed this procedure before on Trusty but I dont recall
>>> seeing Xdummy related warning before either.
>> Which warning?
>> I don't recall which one was the last version of Ubuntu that supported
>> running Xdummy, sorry.
>>
>> Cheers
>> Antoine
>>
>>>
>>> Xdummy – Xpra <https://xpra.org/trac/wiki/Xdummy>
>>>
>>>   
>>>
>>>   
>>>
>>>
>>>    Xdummy – Xpra
>>>
>>> xpra - screen for X
>>>   
>>>
>>> <https://xpra.org/trac/wiki/Xdummy>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>> Mukul ( https://sites.google.com/site/mukulagrawal
>> <https://sites.google.com/site/mukulagrawal>)
>>>
>>>
>>> On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users
>>> <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>> wrote:
>>>
>>>
>>> Thanks for the clarifications.I simplified the setup (non-sudo user for
>>> proxy; same usernames on both machines) to be able to debug. But it
>>> still does not work.
>>> Multifile authentication on proxy succeeds. But seems like it not using
>>> correct ssh command line to connect to backened server.  Logs on the
>>> proxy are attached below. There are no logs on the backend xpra server.
>>> The sshd logs on the backend server says that the connection was closed
>>> by the proxy [preauth].
>>> 1. I now start proxy as non-sudo user1 on machine1 and attach it to
>>> non-priveldged tcp port1. Give it a display number disp1.
>>>
>>>  xpra proxy :disp1 --bind-tcp=0.0.0.0:port1
>>> --tcp-auth=multifile:filename=path-to-multifile -d auth
>>>
>>> Machine1 is running newer version of XPRA (xpra proxy version
> 1.0-r13637).
>>>
>>> multifile looks like following :-
>>> user1|pswd1|1000|1000|ssh:user1 at machine2 <mailto:user1 at machine2>
> <mailto:user1 at machine2 <mailto:user1 at machine2>>
>> <mailto:user1 at machine2 <mailto:user1 at machine2> <mailto:user1 at machine2
> <mailto:user1 at machine2>>>:disp2||
>>>
>>>
>>> 2. start an xpra server on machine2 under the user account with with
>>> same username user1. Give it a display number disp2.
>>>
>>> xpra start :disp2DISPLAY=:disp2 xeyes &
>>>
>>> Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if
>>> this creates any problems.
>>>
>>> 3. Try attaching to backend server on machine2 from machine 1 using ssh
>>> transport and public key authentication.
>>> xpra attach ssh:user1 at machine2 <mailto:user1 at machine2>
> <mailto:user1 at machine2 <mailto:user1 at machine2>>
>> <mailto:user1 at machine2 <mailto:user1 at machine2> <mailto:user1 at machine2
> <mailto:user1 at machine2>>>:disp2
>>> This works fine. So seems like different versions are compatible.
>>> 4. Try attaching from xpra clent running on machine3 (win7 machine).
>>>
>>> xpra attach --password-file=pswd.txt tcp:user1 at machine1
> <mailto:user1 at machine1>
>> <mailto:user1 at machine1 <mailto:user1 at machine1>>
>>> <mailto:user1 at machine1 <mailto:user1 at machine1> <mailto:user1 at machine1
> <mailto:user1 at machine1>>>:port1
>>>
>>> OR
>>> xpra attach tcp:user1:pswd1 at machine1 <mailto:pswd1 at machine1>
> <mailto:pswd1 at machine1 <mailto:pswd1 at machine1>>
>> <mailto:pswd1 at machine1 <mailto:pswd1 at machine1> <mailto:pswd1 at machine1
> <mailto:pswd1 at machine1>>>:port1
>>>
>>>
>>> Proxy Logs :-
>>>
>>> 2016-09-16 11:03:55,160 New tcp connection received from
>>> IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp,
>>> authclass=('multifile',
>>> <class'xpra.server.auth.multifile_auth.Authenticator'>, {'filename':
>>> 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16
>>> 11:03:55,161 creating authenticator ('multifile',<class
>>> 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename':
>>> 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16
>>> 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16
>>> 11:03:55,161 processing authentication withmulti password file,
>>> response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16
>>> 11:03:55,161
>>>
>>
> challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16
>>> 11:03:55,161 Authentication required by multipassword file authenticator
>>> module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using
>>> hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication
>>> withmulti password file, response=864f4fff84caf265599ff84726295167,
>>>
>>
> client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16
>>> 11:03:55,271
>>> mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16
>>> 11:03:55,271 loaded 184 bytes from
>>> 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1:
>>> ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m…. Something here
>>>
>>
> …hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16
>>> 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16
>>> 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<-
>>> IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2
> <mailto:user1 at IP2>
>> <mailto:user1 at IP2 <mailto:user1 at IP2>>
>>> <mailto:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>>>:disp2'], {},
>> {})^[[0m^[[36m2016-09-16 11:03:55,273
>>> start_proxy:proxy-virtual-display=:disp1 (ignored), user specified
>>> display=None, founddisplays=['ssh:user1 at IP2 <mailto:user1 at IP2>
> <mailto:user1 at IP2 <mailto:user1 at IP2>>
>>> <mailto:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>>>:disp2']^[[0m2016-09-16
>> 11:03:55,499 proxy video
>>> encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance
>>> started^[[0m2016-09-16 11:03:55,499 for client tcp socket:
>>> internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server
>>> Pipe(ssh:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>> <mailto:user1 at IP2 <mailto:user1 at IP2>
>> <mailto:user1 at IP2 <mailto:user1 at IP2>>>:disp2)^[[0m2016-09-16 11:03:55,500
>>> proxy instance now also availableusing unix domain
>>> socket:^[[0m2016-09-16
>>> 11:03:55,500
>> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16
>>> 11:03:55,503 Error: SSH connection to thexpra server
>>> failed^[[0m^[[31m2016-09-16 11:03:55,504  check your username, hostname,
>>> displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504  for
>>> server: ssh:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>> <mailto:user1 at IP2 <mailto:user1 at IP2>
>> <mailto:user1 at IP2 <mailto:user1 at IP2>>>:disp2^[[0m^[[31m2016-09-16
>>> 11:03:55,504  the command line used was:^[[0m^[[31m2016-09-16
>>> 11:03:55,504  ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra
>>> _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra
>>> _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection
>>> lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket
>>> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505
>>> proxy instance 11703 stopped^[[0m
>>>
>>>
>>>
>>>
>>>
>>>  Regards, Mukul ( https://sites.google.com/site/mukulagrawal
>>> <https://sites.google.com/site/mukulagrawal>)
>>>
>>>    On Thursday, September 15, 2016 10:24 AM, Antoine Martin via
>>> shifter-users <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>>> wrote:
>>>
>>>
>>> On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote:
>>>> If I want xpra proxy on machine1 to connect to xpra server on machine2
>>> using ssh with public key authentication and no password, then how
>>> should I set it up?
>>> I have not tested this, but SSH connections from the proxy should be
>>> using the public key of the user running the proxy server process and
>>> not the key of the user you authenticate as. (which may not have a user
>>> account at all on the system running the proxy)
>>>
>>>> Public keys are already in default locations and xpra is able to
>>> attach directly from machine2 to machine 1 using standard format:  xpra
>>> attach ssh:username at machine1 <mailto:username at machine1>
> <mailto:username at machine1 <mailto:username at machine1>>
>> <mailto:username at machine1 <mailto:username at machine1>
> <mailto:username at machine1 <mailto:username at machine1>>>:display.
>>> I thought the server you wanted to connect to was "machine 2" and not
>>> the other way around?
>>>
>>>> But when I try to connect via proxy from client machine3, proxy is not
>>> being able to authenticate.
>>> Have you checked your ssh server logs for an answer?
>>>
>>>> It sends the challenge but then there is no log after that.
>>> Please share the log sample up to that point to help clarify things.
>>>
>>> Note: when using SSH connections, the server does not need to use
>>> another socket authentication module. That's usually just redundant.
>>>
>>>> I am using multifile like this :-
>>>> username|pswd|1000|1000|ssh:machine1:display||
>>>> and attach command from machine3 like this:-xpra attach
>>> tcp:username:pswd at machine2 <mailto:pswd at machine2>
> <mailto:pswd at machine2 <mailto:pswd at machine2>>
>> <mailto:pswd at machine2 <mailto:pswd at machine2> <mailto:pswd at machine2
> <mailto:pswd at machine2>>>:proxyPORT
>>>>
>>>> Are the usernames and passwords actually associated with login
>>> accounts on the target machine or their significance is only with
>>> respect to multifile resolution?
>>> It depends: if the proxy server runs as root, each proxied connection
>>> will run as the uid and gid you defined. (ie: 1000 above)
>>> But the connection to the backend server is made before changing uid, so
>>> the ssh key used will not be the one of the user specified in multifile.
>>>
>>> If you don't mind using SSH with passwords, you should be able to use
>>> something like this (untested):
>>> |username|pswd|1000|1000|ssh/username2:password2 at machine2
> <mailto:password2 at machine2>
>> <mailto:password2 at machine2 <mailto:password2 at machine2>>
>>> <mailto:password2 at machine2 <mailto:password2 at machine2>
> <mailto:password2 at machine2 <mailto:password2 at machine2>>>/display||
>>>
>>> We could also change the code to:
>>> * add support for ssh options to multifile, so you could specify the
>>> keyfile for each user
>>> * change the ordering so the connection to the backend server happens
>>> after changing uid and gid (but this would only work with the proxy
>>> running as root)
>>> Feel free to create tickets for this.
>>>
>>>> Can password be left blank for public key authentication?
>>> That doesn't make sense: the password in multifile is for authentication
>>> to the proxy, not to the backend server.
>>> Unless you're trying to connect via ssh to your proxy? (but why?)
>>>
>>> Cheers
>>> Antoine
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> _______________________________________________
>>>> shifter-users mailing list
>>>> shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>>
>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>>
>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>>
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 
>>>
>>>
>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>>
>>
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>>
>>
>>
>>
> 
> 
>