search

ytdl-org / youtube-dl

Command-line program to download videos from YouTube.com and other video sites
http://ytdl-org.github.io/youtube-dl/
The Unlicense
132.43k stars 10.04k forks source link

Allow "file://" URLs #22408

Open atom-smasher opened 5 years ago

atom-smasher commented 5 years ago

Checklist

Description

8228 disabled use of "file://" for good reasons. However not all of us run youtube-dl on a server, and there are instances where treating a local file as a URL with a "file://" protocol is necessary and desired.

While a command-line option to override that security fix would be trivial to circumvent (if youtube-dl is being run on a server), a config-file-only option would retain security where it is needed (and allow that functionality if it's needed on a desktop).

Request: A config-file option to allow use of "file://" URLs (eg "--allow-file-url"). If that option is present on the command-line, youtube-dl should respond either by ignoring it or exiting immediately with a non-zero status.

This would allow a secure method for users to explicitly choose to allow use of "file://" URLs. The default behaviour would remain secure, and it would not be possible to over-ride the secure behaviour via command-line options.

clytras commented 4 years ago

I totally support this. To me, https://github.com/ytdl-org/youtube-dl/pull/8228 was unnecessary. If a user has access to files such as /etc/passwd then that user does not need youtube-dl to get them, they can just cat /etc/passwd or even curl file:///etc/passwd.

ilyadh commented 4 years ago

I support this too. I needed to download a .m3u8 file to tinker with it a little and then run youtube-dl from local.

This restriction is inconvenient and definitely should be an option instead of a fixed behavior.

To work around this, I started a server to serve local files from a directory and then ran youtube-dl http://localhost:3000/list.m3u8

clytras commented 4 years ago

@atom-smasher even on a server, no script or CLI program should be run with elavated access such as root or admins. There are filesystem mechanisms to protect the system. If these CLI tools or scripts are executing with elevated access like sudoers, then the whole system is a big hole that anyone can missuse and pass through.

I do run such scripts and CLI tools on a bunch of servers, but I never run these under elevated user access.

This PR was unnecessary.