Signal on X11 Logout - linux

I am writing an application that will occasionally save data. The Problem is now, when a user logs out of X11 and my application did not yet save the changes, is there a way to detect the logout and write the changes to disk? I tried inmplementing a signal handler for SIGHUP and SIGQUIT without success. Is there a signal that gets emitted or is there a way to lsiten for a logout?

Read ICCCM and EWMH (both are quite large specifications that you should read carefully).
In practice, your X11 application is likely to use some existing GUI toolkit like e.g. Qt or GTK (be sure to use at least GTK3). Then that toolkit should have support related to sessions.
For Qt: look into QSessionManager.
For GTK: see GtkApplication
(if you are stuck with GTK2 - e.g. with lablgtk -, you'll spend months or one or two years of efforts to implement EWMH sessions in your code; porting it to GTK3 -or even to Qt5- should be wiser and might be less work) Since GTK (both GTK2 and GTK3) is free software, you could study the source code (and perhaps be inspired by it, or adapt it to your needs, and/or make an educated guess of the amount of efforts to rewrite it).
Remember that X11 is a network protocol, and the server and the client (and the window manager) could run on different machines (e.g. thru ssh -X). Sending SIGTERM through the network has no sense (and that could explain why EWMH don't mention it).
A workaround might perhaps be to save the state periodically (e.g. every two minutes; then only two minutes of work is lost).

Basile's recommendation of looking at your toolkit's relevant classes (QSessionManager and GtkApplication) is good. I'm thankful he posted that because it helped me find the specific stuff I was looking for.
But if it's as you say, and your toolkit doesn't have built-in session management support, the relevant specification is not EWMH, but rather XSMP. There's a small amount of additional information included in ICCCM that you should also watch out for.
This is far from being a couple years of work. The relevant client-side portions of the session manager protocol should only take a few hours, maybe a couple days if you're unfamiliar with integrating low-level X11 protocols into an existing application stack.

Related

WPP tracing for linux

I'm looking for a way to output traces to a log file in my code, which runs on linux.
I don't want to include the printing information in the binary, in every place I deploy it.
It windows, I simply used WPP to trace without putting the actual traces strings in my binary.
How can this by achieved in Linux?
I'm not very familiar with Linux tools in this area, so maybe there is a better system. However, since nobody else has made any good suggestions, I'll make a suggestion. (Probably not a very good suggestion, but the best I can think of right now.)
In theory, you could continue to use wpp. Wpp is simply a template system. It scans the configuration and input files to create data structures. Then it runs a template, fills in the data values it got from the scan, producing the tmh files. You could create a new set of templates that would use Linux apis instead of Windows apis, and would record the message strings in a way that works with some other log decoder system.
I noticed this question only now and would like to add my two cents to the story just for a case. Personally, I truly appreciate Windows WPP Tracing and consider it probably the best engineering solution for practical development troubleshooting among similar tools.
It happened I extended WPP use to Unix-like platforms twice. We wanted to use strong sides of WPP concept in general and yet use it in a multi-platform pieces of code. This was not a porting but rather a wrapper to specific WPP use we configured on Windows. One time we had a web service to perform actual WPP pre-processing on Windows; it may sound a bit insane but it worked fine and effective within the local network. A wrapper script that was executed before each compilation sent a web request, got a processed file and post-processed the generated include file to make it suitable for Unix-like platforms. The second time we implemented a simplified WPP pre-processor of our own (we found yet additional use for it - we could generate the tracing statements differently for production and unit testing, for example). This was a harsh solution: you anyway need to use some physical tracing framework behind the wrapper on non-Windows platform (well, the first time we apparently implemented our own lower level).
I do not think the Linux world has a framework comparable to WPP. Once I even thought it could be a great idea to make an open source porting project for WPP. I am not sure it would be much requested though. I said it is a great engineering solution. But who wants to do dirty engineering work? Open source community prefer abstract object-oriented and generic solutions, streaming and less necessity in corresponding tools (WPP requires special management tools and OS support).Ease of code writing is the today's choice.
There could be Microsoft fault (or unwillingness) in the lack of WPP popularity too. They kept it as an internal framework that came out just by a case with Windows DDK because they have to offer some logging/tracing solution for driver developers. Nobody even noticed much that WPP is well suitable for the user-space code too. And WPP pre-processor for C#, for example, has never been exposed to public at all.
Nevertheless, I still think that WPP porting to Unix/Linux work can be a challenging, interesting and maybe even useful attempt. If someone decides to lead it. :)

Kiosk program (web browser), deployment struggles

Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?

Drag/Drop between medium/high integrity level processes in Windows Vista

In Windows Vista, I am unable to drag/drop files onto my application's window because it is running as a high integrity level process. I need to run it as high, but I also need to be able to accept dropped files from low/medium integrity level processes like Windows Explorer. I believe it is UIPI that is blocking the drag/drop operation. I know that I can use the ChangeWindowMessageFilter function to allow certain Windows messages to bypass UIPI, but I'm not sure which messages to add to allow the drag/drop operation. Is ChangeWindowMessageFilter the right approach to permit this, or is there a better way? Thanks!
Considering the title of this blog entry:
"Why you shouldn’t touch Change­Window­Message­Filter with a 10-ft pole…",
I guess it is not the best approach ;)
Now, this might seem like a great approach at first - after all, you’ll only use Change­Window­Message­Filter when you’re sure you can completely validate a received message even if it is from an untrusted source, such that there’s no way something could go wrong, right?
Well, the problem is that even if you do this, you are often opening your program up to attack unintentionally.
Consider for a moment how custom window messages are typically used; virtually all the common controls in existence have “dangerous” messages in the custom class message range (e.g. WM_USER and friends).
Additionally, many programs and third party libraries confuse WM_USER and WM_APP, such that you may have programs communicating cross process via both WM_USER and WM_APP, via “dangerous” messages that are used to make sensitive decisions or include pointer parameters.
In the comments of this blog entry, an alternative approach was discussed, but with pretty much the same conclusion:
I would use RegisterWindowMessage and then allow that via ChangeWindowMessageFilter.
However, be aware that you cannot design a cross-process window message interface that passes pointers or other untrusted values or you are creating a security hole.
For this reason, I would tend to avoid using window at all messages for most cross-process IPC (if possible), as it is typically very difficult to do non-trivial things in a secure fashion using them.
Note: this entry "So, who wants to design a feature today?" illustrates the same problem, and points to the insightful articles of Raymond Chen:
Why aren't console windows themed on Windows XP?
Windows Vista has more extended options on the context menu
which both detail the issue.
This ServerFault question "Why can’t I drag/drop a file for editing in notepad in Windows Server 2008?" also includes some answers, but no quick-win.
See also this article on IE

Developing applications expected to run over RDP; any tips?

Supposing I was developing a fairly graphically intensive application (C++ or C#, graphics API undecided) for which most of the usage will be by remote users over RDP (either terminal server sessions or remote access to a single-user machine). It's obvious that non-essential "eye-candy" effects and animations should be avoided. My questions are:
What should I be careful to do/avoid doing to make most efficient use of the RDP protocol ? (e.g I have an idea RDP can remote some graphics drawing primitives straight to the client... but is that only for GDI ? Does using double-buffering break such remoting and force a bitmap mode ? Does the client-side bitmap cache "just work" or does it only cache certain things like fonts and icons ?)
Is there any sort of RDP protocol analyser available which will give some insight into what an RDP stream is actually transporting (in particular, bitmaps vs drawing primitives) ? (I can imagine adding some instrumentation to the rdesktop source to do this, but maybe something exists already).
In my experience I'd be careful when it comes to animations - especially fade up/down controls that can seriously kill performance over RDP.
Double-buffering might also cause some problems, however I personally haven't had to do too much in the way of workarounds for this - the article by Raymond Chen explains the possible pitfalls quite well.
Essentially, it's a good idea to check in code whether it's running in a remote sessions (RDP, Citrix, etc). Take a look at: GetSystemMetrics( SM_REMOTESESSION ) - you can then decide at runtime whether to enable or disable certain features.
My idea is that the optimization work made on RDP already cover 90% of the problem you're describing, so I would not worry about optimizing for RDP, you're already removed the eye-candy stuff, you know that the application will be used via RDP so I suppose you'll avoid operations that involves continuous redrawing of form, I believe that sould be enough.
Our application was never designed with RDP in mind, we had the same worries you have when a customer told us that all its client will be used via RDP (Citrix, in that specific case) from remote locations but also if we didn't change a single line of code the customer never called with slowlyness problems due to RDP.
Remember... Premature optimization is evil.

Keystroke dynamics in Linux

I'm thinking of implementing a keystroke dynamics (authenticating people based on their typing patterns) application for Linux. As I see it, I have two alternatives:
Extend the Linux logon to support keystroke dynamics
Create a desktop-locker program which "locks" the screen and can only be unlocked by a typist with a particular typing pattern
Is alternative 1 possible? Windows supports extending the logon process via msgina.dll, does Linux support something of the sort?
For altenative 2, is is possible to disable the mouse and keyboard?
libpam has plugin ability. so yes, totally possible, like the (in)famous msgina :)
locking the screen is mmm rather touchy - who is responsible? window manager, X server, session manager, the screen saver process, ?
I'm afraid different desktop environments (Gnome, KDE...) might have different opinions. Although these days, I'm pretty positive all of them will share some kind of FreeDesktop dbus interface to coordinate this type of functionality.
Assuming this is more than just a toy (in other words, if you plan to distribute), be sure you think about how to get around the typing pattern analysis when things go wrong. My typing patterns probably change quite a bit over time, as I've got wrist problems that flare up now and then. When they do, my typing probably changes markedly. I wouldn't be too surprised if my typing changes somewhat from morning to night even, as I am more or less tired and/or caffeinated.
Hey, Linux is open source, you could do anything you want :-)
It is very likely that you don't need to modify the kernel. For example, terminal login is controlled by the login program. Changing the source and rebuilding it will definitely allow you to do what you need to, although how difficult it is I've no idea :-)
Graphical login is taken care of by the window manager, so which program to change depends on which window manager you use.
EDIT: On a second thought, I'm not sure if login is executed early enough to catch the keystroke dynamics. Besides, it is a bit risky because if your version of login fails, it could make it difficult to login and fix the problem. You might need to take a look at getty and see how it invokes login. If you do it in a graphical interface it might be easier since you can always fall back to text terminal to fix any problem.
The proper way to do this would probably be through a PAM authentication module. Check out the module writers guide here: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_MWG.html
Basically you can just add your module to the PAM stack, have it do its keystroke analysis, and then pass either success or fail to the system. This lets you integrate it with the console login process, and even SSH if PAM is enabled there. I'm not quite sure how it would work with a graphical login such as KDM or GDM. I know you can use PAM modules with those, but of course the interaction is done through the GUI textbox.

Resources