Cannot connect to nested server when started from a differen vt
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
Medium
|
Alexandros Frantzis | ||
mir (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
launch a server
# sudo ./mir_demo_
switch to vt 2
# sudo chmod 666 /tmp/mir_socket
# ./mir_demo_
switch to vt 3
# ./mir_demo_
Switch to vt 1:
Expected to see Triangle but
ERROR: just a mouse cursor
Switch to vt 3:
egltriangle died with "Can't get connection"
Switch to vt 1
Connect via ssh from a different machine:
# ./mir_demo_
as expected: -> mir_demo_
Switch to vt 3;
# ./mir_demo_
Switch to vt 1
as expected: another egltriangle runs.
Related branches
- Cemil Azizoglu (community): Approve
- Alan Griffiths: Approve
- PS Jenkins bot (community): Approve (continuous-integration)
-
Diff: 282 lines (+72/-117)6 files modifiedsrc/platforms/mesa/include/mir_toolkit/mesa/platform_operation.h (+2/-1)
src/platforms/mesa/server/ipc_operations.cpp (+10/-0)
src/platforms/mesa/server/nested_authentication.cpp (+18/-22)
tests/unit-tests/graphics/mesa/test_guest_platform.cpp (+5/-9)
tests/unit-tests/graphics/mesa/test_ipc_operations.cpp (+17/-0)
tests/unit-tests/graphics/mesa/test_nested_authentication.cpp (+20/-85)
Changed in mir: | |
assignee: | nobody → Alexandros Frantzis (afrantzis) |
Changed in mir: | |
importance: | Undecided → Medium |
Changed in mir: | |
status: | New → Triaged |
Changed in mir: | |
milestone: | none → 0.11.0 |
Changed in mir: | |
status: | Fix Committed → Fix Released |
A description of the underlying cause:
The DRM auth magic cookie used to authenticate file descriptors is tied to, and can only be authenticated against, the DRM master that is active at the time of the drmGetMagic() call.
Currently, when a nested server wants to give a client an authenticated fd, it creates a DRM fd and gets a magic cookie for it. It then sends the cookie to the host for authentication. However, if the nested server gets the magic cookie while the host server is paused (and is therefore no longer the DRM master), the cookie is useless since it is not tied to the proper DRM master (the host). So, when the host server resumes and receives the request to authenticate the cookie, it fails to do so, since the cookie was not registered with it.
A solution is to introduce a mir_connection_ drm_get_ auth_fd( ) client API, so that the host can handle the whole process of creating an auth fd on its own (like it does when sending an authenticated fd when a client connects), avoiding the problem of invalid magic cookies.
The need for an additional platform specific function has triggered some discussions on the topic (see thread [1]) , so I will postpone implementation until a decision has been reached (hopefully by the end of next week)
[1] https:/ /lists. ubuntu. com/archives/ mir-devel/ 2014-October/ 000923. html