mir_demo_server* successfully start without input support as non-root, making them unusable

[Gerry Boland]

On desktop PC

1. Switch to VT1
2. Log in as non-root user
3. Run mir_demo_server_shell
4. Try to stop it and get back to your X session

I'm a Macbook user, so please keep that in mind before suggesting a kernel specific keystroke trick.

This is really annoying, I keep falling into this trap.

[Daniel van Vugt (vanvugt)]

AFAIK, this was intentional. Mir starts best-effort. And if you're not root then you won't get access to input devices.

Though I think we probably should make that a fatal error and prevent Mir from starting...?

[Gerry Boland (gerboland)]

+1 on the fatal error idea. I fail to see the practical use of the best-effort idea, if the best effort locks you out of your machine

[Daniel van Vugt (vanvugt)]

Alternatively we should ask racarr/RAOF if it's possible to get input working for non-root on desktop.

[Chris Halse Rogers (raof)]

It's not possible to get input working for non-root without allowing everyone to snoop on your input; that's not something we can turn on by default.

We *could* install mir_demo_server_shell setuid root, though.

Probably best to just make failure to open any input fatal, though.

[Daniel van Vugt (vanvugt)]

On the various Nexus devices input works as non-root. What's the difference? Does that need *fixing* ?

[Chris Halse Rogers (raof)]

It might need fixing, depending on whether input is multi-readable or not.

If you can open the input device twice, and get events from both fds, then being able to access the input devices means you can capture input.

[Andreas Pokorny (andreas-pokorny)]

We nearly fixed this problem when we switched to input platform probing and dropped the android code base for input reading. With that change there is now code that throws if there is no input platform available to use. Thats the case when no input device is readable and when there is no X11 connection.
A server with insufficient permission to read input could still be stuck when a joystick is connected. Then, because udev rules make that device readable for users and we do start up. This might be a feature for kiosk use cases...

[Daniel van Vugt (vanvugt)]

Confirmed this bug is still happening. And it's not as easy as exiting if there are zero input drivers. Because the input driver loads (just does not respond to any input):

[2016-03-01 17:17:06.258314] mirserver: Selected input driver: mir:evdev-input (version: 0.20.1)

[Andreas Pokorny (andreas-pokorny)]

@duflu: Hum I get an exception "no input platforms found" as mir::evdev-input is not allowed to open any input device in /dev/input. Is it possible that you have a device that can be opened for reading as a user?

[Andreas Pokorny (andreas-pokorny)]

We could also add an automatic shutdown when we have input platforms that claim to work but no input devices available.. This would cover the case that udevd has devices tagged as input, that the server might be able to read from, but which libinput rejects due to lack of support.

The current startup probing only asks udev and tries to open the results.

[Daniel van Vugt (vanvugt)]

Comment #9: Maybe I got a bit further with permissions because I was logged in on VT1 first.

[Daniel van Vugt (vanvugt)]

Still happening...

[Michał Sawicz (saviq)]

Syncing task from Mir.