I am assuming this is a bug.

Being that attachment works hand in hand with the filemanager module, I assumed that attachments using the attachment module would be private. Yet, if I was to browse to the attachment itself (for example http://dbdsites.com/files/active/1/filename.doc), anyone with any access can view or download it.

Comments

tostinni’s picture

Version: » 4.6.x-1.x-dev
Category: bug » feature

Well, I don't think it's a bug because it's never told in attachment features that files won't be accesible directly.

But, I think that it should be a feature request to have the opportunity to set if an attachment would be private or not. Also, filemanager already ahandle private download.

I started to investigate to make a patch, it's not so difficult, in fact I got a working version, but there's some problems (well the only I identify by now) if you want to change the status of a file from private to public (it may not be usefull, but I prefer have the things cleans).
So I don't think I would release it by now.

BTW, if you want a very very simple (a little dirty...) way to change this, edit attachment.module and modify this line :

$file = module_invoke('filemanager', 'add_upload', 'file', 'attachments', FALSE, $new_attachment["fid"]);

By

$file = module_invoke('filemanager', 'add_upload', 'file', 'attachments', TRUE, $new_attachment["fid"]);

So now, all new attachment would be private.
That's not clean but answer your problem for the moment, if I get a little free time and if ccourtne see these messages and give me some feedback, I would consider coding this.

ccourtne’s picture

This can easily be an option in the attachment module. I will be going over the latest furry of issues/patches for these modules sometime next week. I have a board/miniatures gaming convention I'm attending the rest of this week. Switching between private/public after the fact is very difficult, because once the URL to a file is used in a nodes content or off site you can't change it. Although there is the possiblity of doing a private URL always and sending a redirect which I've never gotten around to figuring out.

tostinni’s picture

Hi ccourtne,
Thanks for the answer, as part responsible for the bunch of patch, if I may help, it would be a pleasure. I'm working a lot with your modules right now as I need to deliver my intranet very soon, so if there's some testing, count with me.

The problem with private file is what you describe (I didn't think about URL used offsite, I was focused on changing status from public to private and moving files). So that's why I made warning about modifying private status. I think that private would be better :
- redirect will always work
- if you need to change number of files per directory, or move files, it would be easier to do it with a DB query (change file properties) and it won't break anything.
- you can set up dl counter
...

In fact I don't see any advantage using public link.

bermin’s picture

Count me in on the testing.
My situation is that I am using the module to give a specific role the ability to upload and share files only with members of that role. Everything is cool until you directly access the url to the uploaded file (in which everyone can access it - including anonymous). This is a bit of a security issue (for example - a google search picks up the url to those "private" files).

tostinni’s picture

Hi bermin,
Sorry I didn't catch the update status of the issue.
I was thinking on your problem...
I think there's no issue for the moment, because even "private" dl won't resolve your problem.
Let's explain it.
Even if all your dl are "private", google may reference them by following links and google search will show the files even with a private (which in fact is just a way to prevent direct access to files).
So your problem is that there's no perm by role to access the files. See :

function attachment_perm() {
  return array('add attachments');
}

Solution :
As explained in my last post, I think that direct link to file is obsolete, so I vote for a move on only private files for attachment module (I would write a recently found example of how bad is direct linking at the end of my message).
So once all files set to private, we could set up permissions to access files by roles.
This is very important because in cases like bermin describe, users without right to see the node, may be able to dl the file by browsing to the url (even if it's private, changing fid). So node may be confidential, but attachment not...
With private url and permissions by roles, your files are well protected ;)

I would also add a little help in the INSTALL of the module, regarding how configure apache to prevent browsing and access of the drupal_private (name of my private file folder). It may be very difficult to find this name and then harder to find a filename, but it's better set up too much security than not enough.

If ccourtne agree and need help, I may post a patch resolving this issue, it's not so hard.

Thoughts ?

One more reason to avoid public url for files :
I set up attachment module for my company Intranet and to store our ISO documents. The problem is that users may update these documents without changing the filename. When they browse again the document, if attachment are set to public, IE (I guess FF too, I'm not sure, I didn't test) will first look in its cache if it got a version of the file. If it stored the file, then IE will display our users the locale version of the file, which is a very big problem...
As there is no way (as with meta tags) to tells IE that file was updated, I was unabled to solve the problem.
Using private URL solve this matter.

Who wants going on using public accessible files ?
:D

tostinni’s picture

A little more security, see http://drupal.org/node/30468

Not to self (or everyone who want to contribute) : set up a "view attachement" perm.

ccourtne’s picture

Assigned: Unassigned » ccourtne

I'll add an settings screen to allow people to set the private flag for the attachment module.

ccourtne’s picture

Status: Active » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)