VT freezes when running with suid

[neduard]

The VT freezes after I start orbment.
Last messages are:
Doing work on SUID/SGID side and dropping permissions
Running on VT 3

I added some debugging messages in wlc source and found last call before freeze is ioctl(fd, VT_ACTIVATE, wlc.vt) in wlc/src/session/tty.c
NOTE: it might be that the call is successful, it's just that after it, the VT freezes.

System still responds to SysRq, however none of g, k, v, r, i SysRq combinations seemed to solve anything.

Kernel version: 3.14.36

I should mention I'm running with a custom kernel config, so unless other ideas, I can try using a default one and see if it changes anything.

[Cloudef]

Run with --log option and attach log.

[neduard]

@Cloudef I'm going to attach it here since it's not very big (note it contains some of my own debugging messages showing the ioctl it is about to perform, the next one should have been VT_WAITACTIVATE"):

Date: 2015-03-30 BST
[11:31:33.121] Doing work on SUID/SGID side and dropping permissions
[11:31:33.122] Running on VT 3
[11:31:33.122] setup_tty: E
[11:31:33.122] fstat
[11:31:33.122] minor
[11:31:33.122] major
[11:31:33.122] VT_GETSTATE
[11:31:33.122] KDGKBMODE
[11:31:33.122] KDGETMODE
[11:31:33.122] KDSKBMODE
[11:31:33.122] KD_GRAPHICS
[11:31:33.122] VT_SETMODE
[11:31:33.122] VT_ACTIVATE

I also tried changing my kernel to sys-kernel/debian-sources-3.16.2 (Gentoo) with the full Debian amd64 config but no change.

[Cloudef]

That's weird. All that code does is set the TTY to graphics mode. I'll investigate when I get home.

[neduard]

Thanks!
I looked at Weston-1.7.0 code and noticed the order of the ioctls there is different. I made a few swaps in wlc code and now it actually shows the orbment screen! (complete with animation and mouse movement).
( see neduard/wlc@51e80a3 )

However, when switching VT the whole thing "freezes" (same behaviour as before).

New log: https://gist.github.com/neduard/a2e08139d723c0434b81#file-log-when-switching-vt

I also tried SysRq-e (SIGTERM to all processes) from orbment but screen just goes black and does not respond anymore: https://gist.github.com/neduard/a2e08139d723c0434b81#file-log-with-sysrq-e-combo

[Cloudef]

It sounds like race conditions with the ioctl, there was this sort of bug in some kernel versions.

[Cloudef]

I commited the order change, as this has been confirmed by another person.

[Cloudef]

This should now be fixed, however see issue #102