summaryrefslogtreecommitdiffstats
path: root/player/loadfile.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-01-04 13:48:27 +0100
committerwm4 <wm4@nowhere>2019-09-19 20:37:04 +0200
commitd2ef2f98a861217d1374da9ae039c5cecdbb0e19 (patch)
treeb865d56ec05fe493fa379c836cbc57f56a91429d /player/loadfile.c
parent7fad173cfda06724a0af33091c26eec937d0c6cf (diff)
downloadmpv-d2ef2f98a861217d1374da9ae039c5cecdbb0e19.tar.bz2
mpv-d2ef2f98a861217d1374da9ae039c5cecdbb0e19.tar.xz
loadfile, ytdl_hook: don't reject EDL-resolved URLs through playlist
The ytdl wrapper can resolve web links to playlists. This playlist is passed as big memory:// blob, and will contain further quite normal web links. When playback of one of these playlist entries starts, ytdl is called again and will resolve the web link to a media URL again. This didn't work if playlist entries resolved to EDL URLs. Playback was rejected with a "potentially unsafe URL from playlist" error. This was completely weird and unexpected: using the playlist entry directly on the command line worked fine, and there isn't a reason why it should be different for a playlist entry (both are resolved by the ytdl wrapper anyway). Also, if the only EDL URL was added via audio-add or sub-add, the URL was accessed successfully. The reason this happened is because the playlist entries were marked as STREAM_SAFE_ONLY, and edl:// is not marked as "safe". Playlist entries passed via command line directly are not marked, so resolving them to EDL worked. Fix this by making the ytdl hook set load-unsafe-playlists while the playlist is parsed. (After the playlist is parsed, and before the first playlist entry is played, file-local options are reset again.) Further, extend the load-unsafe-playlists option so that the playlist entries are not marked while the playlist is loaded. Since playlist entries are already verified, this should change nothing about the actual security situation. There are now 2 locations which check load_unsafe_playlists. The old one is a bit redundant now. In theory, the playlist loading code might not be the only code which sets these flags, so keeping the old code is somewhat justified (and in any case it doesn't hurt to keep it). In general, the security concept sucks (and always did). I can for example not answer the question whether you can "break" this mechanism with various combinations of archives, EDL files, playlists files, compromised sites, and so on. You probably can, and I'm fully aware that it's probably possible, so don't blame me.
Diffstat (limited to 'player/loadfile.c')
-rw-r--r--player/loadfile.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/player/loadfile.c b/player/loadfile.c
index bb7365c641..fc3bb97a96 100644
--- a/player/loadfile.c
+++ b/player/loadfile.c
@@ -1429,7 +1429,7 @@ static void play_current_file(struct MPContext *mpctx)
if (mpctx->demuxer->playlist) {
struct playlist *pl = mpctx->demuxer->playlist;
int entry_stream_flags = 0;
- if (!pl->disable_safety) {
+ if (!pl->disable_safety && !mpctx->opts->load_unsafe_playlists) {
entry_stream_flags = STREAM_SAFE_ONLY;
if (mpctx->demuxer->is_network)
entry_stream_flags |= STREAM_NETWORK_ONLY;