webfm to Accept arbitrary extensions for upload

Subscribing: need this in an official release

should be done also in core upload and all file related modules, but I've seen crazy discussions about such an issue preventing a common sense decision.

I'll consider for the next rev. It is already within the administrators rights to set whatever extension they want anyway, however the caveat here is that a malicious uploader could place an evil file on the server that is 'executed'. I think the wildcard option would have to come with a warning. Maybe the choice of a blacklist (with default extensions) rather than a whitelist?

Arbitrary extensions for uploaded files are not accepted even in Drupal core modules.
I would implement the feature in the same way it is implemented in Drupal core code.

It's enough to ask them which files they upload more frequently, or to make clear which files type you allow them to upload.

Modules code must be thought to generally suit all situations; generally speaking, it is not a good idea to accept a file upload without to know which file type is being uploaded (and how the file can be used in the OS running the web server).

A '*' wildcard could be safely incorporated if I implement special handling of files. One option is to encode the contents of the file into a new .php file that has the first line set to a simple 404 header and exit (so much for php file 'execution'). I haven't tested this so there may be efficiency issues. If I went this route it would probably happen in concert with taking files out of webroot.

Many file related modules accept "*" (as an option
Stop being paranoid. As long as the responsibility is to the site administrator (by providing a non default option), the Drupal programmers have nothing to be affraid about.

There must be a reason, if the Default permitted file extensions field used in the File uploads settings page doesn't accept an asterisk like input.

I really don't see the background for this. One can always chose the smarter cck Filefield that don't even need a "*" to explicitely remove any constraint:
"Extensions a user can upload to this field. Separate extensions with a space and do not include the leading dot. Leaving this blank will allow users to upload a file with any extension."

It prudently only allows "txt" by default...

The difference between Drupal, and Linux is that Linux is a OS, not a CMS; the paragon is not appropriate, as an operating system always have more chances to protect itself.

I would agree that modules should try to follow the core general policies.
But here the practice contradicts obsolete or inappropriate policy: Filefield, which is so dangerous and potentially destructive is downloaded 40000 times a week - Web file manager "only" 2500...

If everything that can be misused is to be avoided in core, Drupal should become a set of safe recommendations, letting module developpers bearing all the risks...

I have created an issue against the Core upload module, but WFM might not have to wait for its resolution
http://drupal.org/node/453348

Any follow up?

This is just for making maintenance easier:
I have to remember to add the lline each time the module is updated.

Additional reason for this request (I may have mentionned it already): there are not enough space in the field to define more than a dozen of file extensions, though more than hundred extensions are quite popular.

Looks interesting, what is an RPM?

It's a package file format, mainly used on Linux.

How do you do that?
Does this update a multi-site Drupal install whithout the burden of swithcing off/on modules too?
Is there any recommended ready to use solution for handling that?

Thank you

Thank you all for helping to make webfm better and sharing your thoughts!

Basically this requires some kind of detection of the content - if a server executable file would be uploaded (e.g. php or server side includes) the security of the server could be compromised - thats the problem.
I understand your peoples need on the other hand - the only way I see to implement this is to make use of mimedetect or to implement filefield directly as requested in #206322: Web File Manager File Field for CCK and more extensively discussed in #446818: Use the Drupal "files" Table for file records.

Now I would rather like a filefield implementation, but if someone provides a mimedetect implement which requires mimedetect as an optional module it would be fine. Until then this is a "needs work", sorry :-/

Still thank you all for your work!

In case it would help, I switched to File Framework and all my problems vanished.
For this particular situation, it invokes an antivirus to authorize an upload (just a side feature among an extravagant package). All constraints are configurable.

Not even the Drupal core Upload module allows to set arbitrary extensions; you need to explicitly set the extensions you accept, without the possibility of using wild-chars.
If Drupal core code doesn't offer that possibility, there must be a reason.

These are age old obsolete practices. Extensions are not by far a reliable means to detect a possible threat.
File Framework does not restrict upload by default and check files using the available server antivirus (Clamav for example)
For paranoid people, an optional module allows any kind of restrictions.

WARNING: SOAPBOX ON.. lol

IMHO, protecting security ignorant people from themselves is a high priority in any PhP application. There is enough perception out there that PhP is unsecure because of all the hacked PhP sites (like phpNuke and it's ilk). Drupal has a good reputation for being secure (enough that Whitehouse.gov is using it...), but if Drupal sites start being hacked because of "I know what I'm doing so I turned off security" problems, the perception will be that Drupal is unsecure... even thought it was the admin who was at fault. Personally, protecting the Drupal's security reputation by being conservative on stuff like this is much more important than making it convenient for the few cases that *NEED* take chances with wildcard extensions.

SOAPBOX OFF...

That said, IF a file upload module was to allow any extension, I'd expect there to be a couple of golden rules:

1) If enabled, a test to see if there is security in place that disallows direct access. E.g. that .htaccess blocks direct URL calls to any uploaded .php files. E.g., the admin screen does an ajax call to test if the file store is "open" or not. If open access is allowed, you can't use it.

The reason behind this is to prevent people from executing malicious code on your server. E.g. uploading a php file that will change the admin password via direct database calls, then running it via calling the direct web url which makes the uploaded php file execute in on your server. The .htaccess will make files only available via the webfm URLs.

This doesn't protect the users who DL and run Trojan exes from your site, but at least your site won't easily be hacked.

2) That there is a big WARNING: DO NOT USE UNLESS YOU KNOW WHAT YOU ARE DOING! message... possibly with multiple "Yes I'm REALLY sure" confirmations. Just to make sure people turning this on at least think about the security implications and not just the usability / convenience side of things.

Just my 2$/EU worth.

Would be a nice feature. I have many different extensions here. To add all 26^3 possible 3 char combinations is from optimal. cgmonroe already give some simple handguides to make it secure.