Request: download directory as zip

[timbertson]

I'd quite like this feature, for sharing files with users who don't want to set up a webdav client just to grab a batch of files.

I was looking at the code, and it seems like it would be nice to use the dav server's tree functionality, but to build a zip on the fly rather than whatever stream dav pumps out. But I couldn't see a good way to access the dav server's functionality directly, it only seems to expose a low-level HTTP handler.

So then I looked into adding zip support by using something like https://github.com/archiverjs/node-archiver to add a download endpoint independent of the DAV stuff. But that feels pretty dodgy, as you then have to double up the security / validation (which I'm hoping DAV does) for issues like requesting paths outside of the DAV folder, or zipping up a directory with symlinks to /etc/passwd

Do you have any plans for this feature, or advice on what the best approach might be?

[paulproteus]

Hi @timbertson !

I'm a Sandstorm core developer, and for what it's worth, I think it's OK to zip up the entire grain.

Keep the following in mind:

• The "app package", namely the SPK file descried at https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdyx97ytn8hq71mdzv4p4d8n0n3h , is the only thing providing files in the grain, except for data the user adds.
• Therefore, there is nothing secret within the grain except the user's data.
• Therefore, any symlink abuse is just at the user's own expense.

See also:

"Sandstorm's server container maps the app's package (libraries, assets, etc.) read-only, and maps the per-grain writable storage at /var. Thus, apps are stateful, yet assets can be shared between many instances of the app." https://docs.sandstorm.io/en/latest/using/security-practices/#threat-models

[mnutt]

Zipping up the entire grain is an easy way to do it, though I can understand certain use cases where that may not be doable. (I set up a shared directory of photos, send it to you read-only, you want to download the entire thing at once, without a desktop client)

I'm not sure if it can fit into the webdav API, but would be open to seeing how it might fit in. I'd have an easier time fitting it in as a call outside webdav that fetches the files via webdav and zips them up, probably using something like node-archiver. Similar to the web UI uploader, probably?

If you'd like to take a crack at it, I'd be happy to accept a pull request!

[ocdtrekkie]

I feel like this is another place where it should be highlighted (@paulproteus) that Sandstorm needs to let app developers delegate the download backup role to some roles that can be shared with users.

I feel like it would be sad to implement a "zip up the entire grain" feature, when said feature already exists in Sandstorm: "Download Backup".

[paulproteus]

@ocdtrekkie then please do make sure there's a Sandstorm bug for this! :) I don't know that we'll get to it super-soon, but I agree with you.

[ocdtrekkie]

I think the clone grain issue on Sandstorm talks about this case. I see them as much the same. That we need to delegate in-Sandstorm cloning and the download backup feature.

[paulproteus]

Fair enough!​

[mnutt]

Makes sense to me. A shared directory is the smallest unit of access control, so if you have read access then it would be fine to let you download a backup of the entire grain. I can still see how a user may want to download a subset of the shared directory, though.

[timbertson]

Thanks for the feedback folks, I've taken a crack in a PR. Fair point that zipping up the grain does most of this anyway, but I think it's convenient to be able to selectively download subfolders anyway.