starred/youtube-dl

Fork 0

mirror of https://github.com/ytdl-org/youtube-dl.git synced 2026-03-02 23:07:04 -05:00

Allow "file://" URLs #17970

New issue

Open

opened 2026-02-21 08:27:22 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-21 08:27:22 -05:00

Owner

Originally created by @atom-smasher on GitHub (Sep 15, 2019).

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.

Originally created by @atom-smasher on GitHub (Sep 15, 2019). ## Checklist - [x] I'm reporting a feature request - [x] I've verified that I'm running youtube-dl version **2019.09.12.1** - [x] 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.

deekerman added the

request

label

2026-02-21 08:27:22 -05:00

deekerman commented

2026-02-21 08:27:24 -05:00

Author

Owner

@clytras commented on GitHub (Mar 6, 2020):

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.

@clytras commented on GitHub (Mar 6, 2020): 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`.

deekerman commented

2026-02-21 08:27:26 -05:00

Author

Owner

@ilyadh commented on GitHub (Apr 17, 2020):

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

@ilyadh commented on GitHub (Apr 17, 2020): 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`

deekerman commented

2026-02-21 08:27:26 -05:00

Author

Owner

@clytras commented on GitHub (Apr 20, 2020):

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

@clytras commented on GitHub (Apr 20, 2020): @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.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/youtube-dl#17970

No description provided.

Rows
Columns