We don't want one client to modify the keymap sent to others. It will
cause crashes or worse.
This patch reopens the file after it has been set to read only, then
unlinks the original file.
BUG: 381674
KWin |
We don't want one client to modify the keymap sent to others. It will
cause crashes or worse.
This patch reopens the file after it has been set to read only, then
unlinks the original file.
BUG: 381674
Ran test attached to the bug
future dolphin instances start up without crashing
those instances seem to have a working keymap
Lint Errors | Excuse: adf |
Severity | Location | Code | Message |
---|---|---|---|
Error | input.h:310 | Cppcheck | unknownMacro |
No Unit Test Coverage |
Buildable 23831 | |
Build 23849: arc lint + arc unit |
xkb.cpp | ||
---|---|---|
297 | Would it be okay if the QTemporaryFile is allocated on the stack? e.g. QTemporaryFile keymapFile; (asking out of curiosity) | |
313 | Noob question: why do we need another QFile object? I'm just trying to understand why we can't do something along these lines tmp->setPermissions(QFileDevice::ReadOwner); m_seat->setKeymap(tmp->handle(), size); |
xkb.cpp | ||
---|---|---|
297 | Yes it should be possible, we would need to find a way to do the reset part though, so just removing the file. |
xkb.cpp | ||
---|---|---|
313 | I tired that first. Both with Qt API as well as fchmod directly on this fd and on a dup'd version. It didn't work. There's a really good test in the bug report |
Fwiw, I checked wlroots.
They seem to have a mmaped address per client and copy keymap contents to everyone individually, which obviously also is safe.
I wouldn't mind either solution (this one or D14910).
His has a unit test. Lets do that.