Allow "file://" URLs

[atom-smasher]

Checklist

• I'm reporting a feature request
• I've verified that I'm running youtube-dl version 2019.09.12.1
• I've searched the bugtracker for similar feature requests including closed ones

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]

I totally support this. To me, #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]

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]

@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.