Uploads world readable #320

Open
virtuaris opened this Issue Nov 19, 2015 · 13 comments

Projects

None yet

5 participants

@virtuaris

Hi there,
i just noticed that the contents stored in folder /home/zulip/uploads/files/ are readable to everyone. No session/authentication needed. Just head your browser to https://my-custom-zulip-server.mydomain.net/user_uploads/x/y/zzzzzzzzzzz/the_uploaded_file.something and off you go.
Is this the expected behaviour?
(zulip 1.3.7, ubuntu 14.04)
Bests
Harald

@timabbott
Member

This is expected behavior for the locally hosted file uploads, but we should definitely add documentation of this in the discussion of local file uploads vs. S3 hosting (which does have a model that checks auth and then redirects to a short-lived auth token).

I think the approach we're planning to take for fixing #291 would be the first step towards changing the way local file uploads work to match the S3 implementation.

@asmartin

+1 keeping uploads private to just the user who posted it and the members of the stream or private message where the uploader posted it is important to my environment

@timabbott
Member

@asmartin is it possible for you to use the S3 integration in your environment?

@asmartin

No, unfortunately all uploads must be hosted locally

@timabbott
Member

OK. A potential workaround is to use the S3 integration with something that implements the S3 API like Eucalyptis, but I agree the local file upload integration needs to support access controls.

@asmartin

What about when an upload is done, an entry is created in the database with the upload filename and also a list of the users in the stream where the upload was made. Then rather than exposing the files directly, require that they be served by a script which checks this entry to make sure the requesting user is in the list. This would have the added benefit of ensuring that someone who got added to the stream after the fact could not get access to files from before they were a member. For private messages this is easy, since the only the other person in the private message would have access.

@timabbott
Member

Yeah, that's roughly the approach I had in mind. Implementation-wise, I'd do it in two phases:
(1) Make the local uploads integration controlled by Django and use the same codepath as the S3 integration.
(2) Change that codepath to track exactly which users have had the file shared with them.

@wama881
wama881 commented Mar 16, 2016

Hi Tim, Is there a timeline when the two phases you mentioned above will be implemented? And is there a way to get all uploaded files for a specific stream? Thanks.

@timabbott timabbott added the priority label Mar 16, 2016
@timabbott
Member

There isn't a timeline -- most new feature development right now is driven by individual contributors deciding its worth working on an issue; we don't have a centralized planning process (though I'm hoping to set one up in the next month or two).

Right now, my time is currently absorbed with managing the 40 open pull requests we have due to Zulip being very popular with Google Summer of Code applicants. I've added a priority tag to this issue to make it clear I consider this one of the more important issues for someone to work on and as a reminder to myself; this will hopefully encourage GSOC students and other contributors looking for a project to work on this.

@timabbott timabbott added this to the 2016 roadmap milestone Apr 29, 2016
@timabbott
Member

Just as an FYI to the folks on this thread, there's ongoing work on this project here: #769

@timabbott
Member

Just a quick update, we just merged most of #769 into master. While there's more work planned as part of #769 to improve the performance of the new implementation (in particular, having nginx serve locally-uploaded files again, rather than Python), this does work now.

I just realized a bug in the new functionality, though; files uploaded before the Attachment model was introduced in 1.3.13 will be inaccessible with this version of the software. We'll discuss that on the #769 thread.

@timabbott
Member

Due to that bug, I reverted the enforcement commit from #769, so we can't close this quite yet. But I think it's likely we'll have this resolved for the next release!

@brainwane
Contributor

I ran into this issue today.

@timabbott timabbott modified the milestone: Zulip roadmap, Old roadmap Nov 18, 2016
@timabbott timabbott added a commit to timabbott/zulip that referenced this issue Feb 8, 2017
@rahuldeve @timabbott rahuldeve + timabbott Add authorization check before serving files.
This is a remerge of e985b57 (after
resolving merge conflicts, updating the tests, adding mypy annotations
etc.), which should now be correct, because we've done the necessary
database migration.

This fixes an important part of #320.
bcc21d2
@timabbott timabbott added a commit to timabbott/zulip that referenced this issue Feb 9, 2017
@rahuldeve @timabbott rahuldeve + timabbott Add authorization check before serving files.
This is a remerge of e985b57 (after
resolving merge conflicts, updating the tests, adding mypy annotations
etc.), which should now be correct, because we've done the necessary
database migration.

This fixes an important part of #320.
511dabf
@timabbott timabbott added a commit to timabbott/zulip that referenced this issue Feb 9, 2017
@rahuldeve @timabbott rahuldeve + timabbott uploads: Add authorization check before serving files.
This is a remerge of e985b57 (after
resolving merge conflicts, updating the tests, adding mypy annotations
etc.), which should now be correct, because we've done the necessary
database migration.

This is an important part of #320.
cef9f67
@timabbott timabbott added a commit to timabbott/zulip that referenced this issue Feb 9, 2017
@rahuldeve @timabbott rahuldeve + timabbott uploads: Add authorization check before serving files.
This is a remerge of e985b57 (after
resolving merge conflicts, updating the tests, adding mypy annotations
etc.), which should now be correct, because we've done the necessary
database migration.

This is an important part of #320.
11bf58f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment