summaryrefslogtreecommitdiffstats
path: root/input/ipc-win.c
Commit message (Collapse)AuthorAgeFilesLines
* all: replace mpv_detach_destroy() with mpv_destroy()wm42018-03-151-2/+2
|
* ipc: log when listening to IPC socketwm42016-09-291-0/+2
| | | | Fixes #3598.
* client API: declare mpv_suspend/mpv_resume deprecatedwm42016-09-161-5/+1
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* ipc-win: restrict read access to the IPC pipeJames Ross-Gowan2016-03-251-2/+96
| | | | | | | | | | | | | | | The default security descriptor for named pipes in Windows allows the pipe to be opened for read access by the Everyone group and Anonymous account, as well as low-integrity processes (like web browser renderer processes.) This does not allow commands to be ran, but it does allow events to be received. I don't think any sensitive data is exposed by events, but that may not always be the case and Lua plugins might change this, since they can broadcast their own events with script-message. To be safe, this commit sets a custom security descriptor on the named pipe which only allows access from processes running under the same user account with an integrity level greater than or equal to the one used by mpv.
* ipc: add Windows implementation with named pipesJames Ross-Gowan2016-03-231-0/+408
This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.