• Working inside an XSession.
  • Some (background) deamon needs to prompt me for password input.

How can I make the daemon to prompt me for a password using a popup in the Xsession?

The daemon normaly normaly has no linkage to the X Session which makes it hard to spawn a prompt password popup-window.

Some ideas for answers:

  • a small program that executed (fork/child from) the daemon which makes a X-prompt-popup-window best. the smaller the better :)
  • safety first Even though I doubt possible, any solution that makes sure that while entering password no other application running in that X Session can keylog is much appreciated.

This kind of problems is usually handled by having two stand-alone binaries: the service daemon and the user interface that communicate over a UNIX domain socket (or a network socket in case they are not running on the same machine). A prime example would be OpenSSH - check how ssh-agent, ssh-add and ssh interact to get some idea how this can be done. Replace "UNIX domain socket" with "D-Bus" if you want to get trendy or need some extra functionality that you'd have to implement.

If the action request is coming from the daemon itself (which if I understand correctly) is your particular case, it is a bit trickier. The UI part should get spawned sometimes during the X session, register itself with the daemon and when the daemon decides it needs some input, it asks the UI part to do its stuff. The last two sentences are actually where D-Bus might come in handy.

On the other hand, you should consider carefully, whether daemon actively asking for a password is the Right WayTM of doing things - daemons are usually services which answer requests rather than generating one. It might be better to let the UI actively push the password in, when user decides it is time to do that. I'm not saying that is the only good approach, just that it should be considered thoroughly first.

As far as security is concern, everything depends on how paranoid you want to get. With X you can grab the keyboard (see XGrabKeyboard(3) man page) which should give you reasonable level of security. Or better put: if you don't use it, you have no control of the password whatsoever. Again, ssh is a good example: have a look at the x11-ssh-askpass helper. Its homepage doesn't seem to work any more, but you can find the sources in many places, for example in the openSUSE BuildService.

You can actually even use it directly, since all it does is grabbing the keyboard and outputting the entered password on its standard output, so all you need is to spawn the askpass helper and check its stdout. If I recall correctly, readpass.c in OpenSSH should give you some idea about how to do it.

While all this may look a bit overcomplicated and far from secure, there are several things to consider:

  1. several projects usually considered reasonably secure like OpenSSH and GPG use this approach.

  2. Security is hard. Rolling out one's own security solutions usually ends with troubles (or disasters) one way or another (it can also become the usual enterprise-y: "I've got this cool thing." - "Wow, let's make it a new company tool" - 5 years later: "It's completely inextensible/broken/insecure/... - how could have anybody made this a company-wide solution?!" Substitute "company-wide solution" with "our flagship product" for hours of laughter). Also see the canonical Security SE Q&As: https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own and https://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology.

  3. Keyboard grabbing doesn't say anything about any other application not eavesdropping on the keyboard events somewhere deeper in the stack (i.e. under the X application layer). But then again, such an application would very likely require some sort of root access, hence if you had something like that on the system, you might as well put the passwords into a plain text file named passwords.txt in your home directory).

| improve this answer | |
  • 1
    Thank you for eluding to the conceptional background. In the case here the thing is to unlock a USB-pendrive when inserted. Somehow the udev-deamon starts a script which to unlock would need to get the password/key from the user. I think I let the daemon simply temporarily switch (chvt) to a free vt and prompt there for I understand I escape X keylogging problem after all. Also a prompt program on the console is easier made as the mentioned UI part of the schema suggested. – humanityANDpeace Oct 26 '14 at 10:25
  • 1
    If you switch to Linux console, you'd have to let the user log in first, then get the password and logout, otherwise it will be security hole as well. And finding a free VT is generally not always possible. My suggestion is at least looking at the x11-askpass (see updated answer) - it's not that difficult. – peterph Oct 26 '14 at 13:30
  • 1
    Thank you for the suggestions. The problem with the X11 Server and apparent impossible keylogger safety ( askubuntu.com/questions/115669/… ) does not motivate much going the X11 way at all. Since I trust the person in front of the keyboard I do not perceive the security weakness simply using say /dev/tty4 for input of the password without a prior login. Sure some already root priviledged rogue process could attack the chvt way of input, but at this point there was no security anymore. Still many thanks for the x11-askpass suggestion. – humanityANDpeace Oct 26 '14 at 13:55
  • 1
    Well, the Q&A at askubuntu are rather wrong when it comes to keyboard grabbing (including the answers) - it is not a security flaw, it is a design decision in X windows (no matter how unwise it may seem). Of course, gnome terminal (or any other application) doesn't grab the keyboard (most of the time) - yet why would it? And that is why OpenSSH and GPG use standalone applications that do grab the keyboard. If you are happy with their security level, there's no need to do it otherwise. – peterph Oct 26 '14 at 15:11
  • 1
    Also see updated answer with the link to an example. :) – peterph Oct 26 '14 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.