How to limit storage space per grain?

[Steven Phillips]

I have scoured the docs and can't find a way to limit how much space in /var can be taken up by an app or a grain.

I am trying to limit storage space by grain.  Is this possible at present?  Thanks!

[Asheesh Laroia]

Hi there!

I believe there is no way to do that yet. If it's important to you, then I hope you'll file a bug and we can figure out the details on the bug tracker!

On Thu, Feb 18, 2016 at 10:28 PM, Steven Phillips <elimi...@gmail.com> wrote:

I have scoured the docs and can't find a way to limit how much space in /var can be taken up by an app or a grain.

I am trying to limit storage space by grain.  Is this possible at present?  Thanks!

--
You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kenton Varda]

Hi Steven,

I'm interested to know your motivation here. Are you concerned that other users with whom you've shared the grain will upload too much data and fill your storage?

-Kenton

[Steve Phillips]

That is one concern, yes.  Another, related case is where I create a new grain for a friend, give them an API key or invitation, allow them to back up their data to my server, but thereby risking that they take up too much space.

I'm also thinking through the idea of providing a "cloud storage" service of sorts, one user per grain, where programmatically limiting their data storage would be of greater importance, since I wouldn't know them, would trust them less, and not only could they fill up my HD, inconveniencing me, but doing so would also take up space that should be used by other users, thereby interfering with them.

In all 3 of these cases, being able to limit how much space a user, API key, or (preferably) grain can use up would be important.  That said, right before accepting a new file upload, my app could always do the equivalent of  du -h /var  to see how much space that grain has used, and reject new uploads if it would put them over their limit, so having this feature built into Sandstorm is not of utmost importance, even for implementing all 3 ideas mentioned above.

[Kenton Varda]

Hmm, it sounds to me like what you really want is per-user quotas, like Oasis has, but in self-hosted Sandstorm. I would argue that you shouldn't be creating grains for specific friends, but rather giving them permission to create their own grains. At least, that's how Sandstorm is designed to work.

The main reason per-user quotas aren't implemented in self-hosted Sandstorm today is because I haven't thought of a good way to do it. Oasis has a custom storage back-end which explicitly implements quota management, but self-hosted Sandstorm uses the plain old filesystem, where it's not so easy. Maybe it would be reasonable to implement based on the same logic that displays the grain size in the top bar -- we could periodically query that size while the grain is running, and assume the last-observed size is accurate. This wouldn't be hack-proof, but probably your friends aren't going to implement elaborate hacks to fool your quota enforcement?

-Kenton

[Steve Phillips]

Hmm, it sounds to me like what you really want is per-user quotas, like Oasis has, but in self-hosted Sandstorm. I would argue that you shouldn't be creating grains for specific friends, but rather giving them permission to create their own grains. At least, that's how Sandstorm is designed to work.

Per-user quotas would solve the friend case, you're right.

Retaining User Anonymity

For users that want high degrees of anonymity and don't want to connect via Google, via GitHub, nor have unencrypted emails flowing from my server through Sendgrid/Mailgun/Mandrill to their email provider, it's hard to beat handing out API keys via some encrypted channel.

Now, one solution that would scale better for my obscure and seemingly odd anonymous-users-store-their-crap-on-my-server use case, as well as be much more broadly applicable to other Sandstorm users, would be to have passwordless logins via GPG-encrypted email!  (In an issue you mention decentralized GPG login, which may be similar?)

In that case there would still be a record of who has an account on my Sandstorm installation (by email), but that's not so bad.  Plus, everyone has email, but not everyone has GitHub or Gmail.

Note that GPG-encrypted email invites are not as important, because at /admin/invites I can create a link and GPG-encrypt it myself, unlike passwordless login emails, and that invitation process is manual anyway (for me, the administrator), also unlike passwordless login emails.

So, long story longer, having per-user storage quotas + passwordless logins via GPG-encrypted email would rock, for both usability and privacy reasons; users could then use Sandstorm as designed, and avoid having to create GitHub or Gmail accounts, as well as avoid having GitHub or Google know they have an account on my server and know every time they log in.

Maybe it would be reasonable to implement [per-user quotes on self-hosted Sandstorm] based on the same logic that displays the grain size in the top bar -- we could periodically query that size while the grain is running, and assume the last-observed size is accurate. This wouldn't be hack-proof, but probably your friends aren't going to implement elaborate hacks to fool your quota enforcement?

My friends wouldn't, I agree, but why wouldn't this be hack-proof?  Just because of the time delay between that figure being updated?

Quota Calculation

In case one is much easier to implement than the other, either having data count against a user's quota when a user owns the grain storing that data, or in the case that the user has access to said grain (like Dropbox does it -- if a folder containing 100MB is shared, everyone it's shared with has that folder count against their storage quota by 100MB, which also prevents users from pooling storage space from many free accounts), would be fine for the use cases I have in mind.  I'm not sure how Oasis does it now.

Thanks for reading!

[Kenton Varda]

On Fri, Feb 19, 2016 at 11:23 PM, Steve Phillips <st...@tryingtobeawesome.com> wrote:

Now, one solution that would scale better for my obscure and seemingly odd anonymous-users-store-their-crap-on-my-server use case, as well as be much more broadly applicable to other Sandstorm users, would be to have passwordless logins via GPG-encrypted email!  (In an issue you mention decentralized GPG login, which may be similar?)

The GPG login plan is actually even more anonymous: there is no email involved, just a key pair. The user's "identity" is their key fingerprint. They log in by proving they own the corresponding private key.

This seems like it solves your problem, but unfortunately I'm not sure when we'll get around to implementing this.

Maybe a shorter-term compromise would be for you to set up an LDAP server with usernames and passwords. We'll be adding LDAP login soon, as part of "Sandstorm for Work". Assuming your use case isn't profit-oriented, I'd be happy to give you a free feature key to unlock this feature (or you could build from source and remove the feature key check, but then you don't get auto-updates).

Maybe it would be reasonable to implement [per-user quotes on self-hosted Sandstorm] based on the same logic that displays the grain size in the top bar -- we could periodically query that size while the grain is running, and assume the last-observed size is accurate. This wouldn't be hack-proof, but probably your friends aren't going to implement elaborate hacks to fool your quota enforcement?

My friends wouldn't, I agree, but why wouldn't this be hack-proof?  Just because of the time delay between that figure being updated?

Because the counting is based on filesystem scanning and inotify events. inotify is a terrible interface, and as a result it's almost certainly possible to perform a sequence of filesystem operations which result in some file not being properly counted.

-Kenton

[Asheesh Laroia]

Just to add one more thought to this:

On Fri, Feb 19, 2016 at 11:23 PM, Steve Phillips <st...@tryingtobeawesome.com> wrote:

Hmm, it sounds to me like what you really want is per-user quotas, like Oasis has, but in self-hosted Sandstorm. I would argue that you shouldn't be creating grains for specific friends, but rather giving them permission to create their own grains. At least, that's how Sandstorm is designed to work.

Per-user quotas would solve the friend case, you're right.

Retaining User Anonymity

For users that want high degrees of anonymity and don't want to connect via Google, via GitHub, nor have unencrypted emails flowing from my server through Sendgrid/Mailgun/Mandrill to their email provider, it's hard to beat handing out API keys via some encrypted channel.

Now, one solution that would scale better for my obscure and seemingly odd anonymous-users-store-their-crap-on-my-server use case, as well as be much more broadly applicable to other Sandstorm users, would be to have passwordless logins via GPG-encrypted email!  (In an issue you mention decentralized GPG login, which may be similar?)

In that case there would still be a record of who has an account on my Sandstorm installation (by email), but that's not so bad.  Plus, everyone has email, but not everyone has GitHub or Gmail.

Note that GPG-encrypted email invites are not as important, because at /admin/invites I can create a link and GPG-encrypt it myself, unlike passwordless login emails, and that invitation process is manual anyway (for me, the administrator), also unlike passwordless login emails.

So, long story longer, having per-user storage quotas + passwordless logins via GPG-encrypted email would rock, for both usability and privacy reasons; users could then use Sandstorm as designed, and avoid having to create GitHub or Gmail accounts, as well as avoid having GitHub or Google know they have an account on my server and know every time they log in.

If you can deal with the following:

- Sandstorm sends a "passwordless login email" to the person, and

- A somewhat simplistic piece of software (e.g. Python script, ~100 line go program) receives the mail and GPG encrypts it to the recipient, and

- Only then does the email pass into the normal email network...

...then this is something that the Tor Project also wants for https://storm.torproject.org/ , which is their Sandstorm server. You'd have to have a config file or similar for what keys to trust, and there might be some other wrinkles, but it seems to me that's doable outside of Sandstorm, and if you were to make that, I think it would solve your problem!

What do you think? Possibly interested in making it happen? (-:

[Steven Phillips]

@kentonv Sorry for the slow response.

Maybe a shorter-term compromise would be for you to set up an LDAP server with usernames and passwords. We'll be adding LDAP login soon, as part of "Sandstorm for Work". Assuming your use case isn't profit-oriented, I'd be happy to give you a free feature key to unlock this feature (or you could build from source and remove the feature key check, but then you don't get auto-updates).

I really appreciate that!  My project is indeed not profit-oriented, but "helping activists (who tend to be poor)"-oriented.  My only concerns are (1) is there a non-shitty LDAP server on Linux?, and (2) if I were truly effective in helping activists then there could eventually be political pressure put on the Sandstorm team to retract the LDAP login.

@asheesh

 

If you can deal with the following:

- Sandstorm sends a "passwordless login email" to the person, and

- A somewhat simplistic piece of software (e.g. Python script, ~100 line go program) receives the mail and GPG encrypts it to the recipient, and

- Only then does the email pass into the normal email network...

...then this is something that the Tor Project also wants for https://storm.torproject.org/ , which is their Sandstorm server. You'd have to have a config file or similar for what keys to trust, and there might be some other wrinkles, but it seems to me that's doable outside of Sandstorm, and if you were to make that, I think it would solve your problem!

What do you think? Possibly interested in making it happen? (-:

Wow, this is fascinating for 2 reasons: (1) because I was thinking along the exact same lines (regarding how to implement GPG encryption on top of Sandstorm as it currently is), and (2) because "this is something that the Tor Project also wants" is one of the most wonderful things I've ever heard.

I love the Tor Project in general, plus Jacob Appelbaum is one of my heroes.

Is it possible to implement this without mucking around in the C++ code?  Hopefully throwing some conditional logic into the JS code that checks "a config file or similar for what keys to trust", as you put it, or perhaps MongoDB?  Or would that be too invasive from Sandstorm's perspective?

Exciting possibilities!  Thanks guys.

[Asheesh Laroia]

Hi! Answering inline.

The easiest way to do this, in my opinion, is to set SMTP_URL in Sandstorm to a SMTPd that is a (e.g.) Python script that listens on SMTP.

If the inbound email is a login email, which it detects via some heuristic (later on, we can start to set a X-Sandstorm-Purpose: passwordless-email-login-token header), then it GPG-encrypts it to the recipient.

Or, maybe it GPG-encrypts all mails to the recipient if it has the keys.

In that case, you could manage this tool and its configuration entirely outside Sandstorm.

Personally, I like that because it means that we aren't a showstopper for this tool working; you can create it and document how to integrate it without waiting for us to do anything.

What do you think?

Cheers,

Asheesh.

[Steve Phillips]

The easiest way to do this, in my opinion, is to set SMTP_URL in Sandstorm to a SMTPd that is a (e.g.) Python script that listens on SMTP.

That sounds awesome aside from having this fresh new SMTP server being considered spam my Google and Yahoo and everyone else's servers... but it could almost pretend to be an SMTP server and really send encrypted emails to SendGrid/Mandrill/etc to really send them.

Or, maybe it GPG-encrypts all mails to the recipient if it has the keys.

In that case, you could manage this tool and its configuration entirely outside Sandstorm.

Even aside from the not-needing-Sandstorm-integration-per-se aspect, GPG-encrypting all mails "if it has the keys" sounds really promising and simple.  My only concern there are bugs where maybe someone's email is stored as firstnam...@gmail.com and then it's also referenced as firstname.last...@gmail.com -- with the dot -- which isn't picked up by the script, and then a plaintext email is sent.

If there's a setting somewhere which says that all emails to a certain user must be encrypted... well, but the above bug would cause problems here, too.

Actually, for the very sensitive use cases I have in mind, it'd be better to only send the person a passwordless login email if it has their GPG key, else it returns an error saying it can't log them in without their key.

GPG or bust.

Personally, I like that because it means that we aren't a showstopper for this tool working; you can create it and document how to integrate it without waiting for us to do anything.

What do you think?

I really think this sounds amazing and I'm going to work on this ASAP.  You said people at Tor want this, too?  They probably have about the same use cases in mind as I do...  If there's any more info you can pass along there related to who I should contact or what stage they're at with Sandstorm or whatever, please send me an encrypted email.  You can import my key with this command:

$ gpg --keyserver pgp.mit.edu --recv-keys 0x3F8AA1E2

set SMTP_URL in Sandstorm

Are you talking about the setting one set in the web UI as the admin of a Sandstorm server?  Or can this be set as env var, or some other option?  Thanks!

--Steve

[Asheesh Laroia]

On Thu, Mar 3, 2016 at 11:18 PM, Steve Phillips <st...@tryingtobeawesome.com> wrote:

The easiest way to do this, in my opinion, is to set SMTP_URL in Sandstorm to a SMTPd that is a (e.g.) Python script that listens on SMTP.

That sounds awesome aside from having this fresh new SMTP server being considered spam my Google and Yahoo and everyone else's servers... but it could almost pretend to be an SMTP server and really send encrypted emails to SendGrid/Mandrill/etc to really send them.

Yes - then relay it to SendGrid/Mandrill/etc. That's what I mean! Glad that concept came through, even if by you creating it separately from me.

 

Or, maybe it GPG-encrypts all mails to the recipient if it has the keys.

In that case, you could manage this tool and its configuration entirely outside Sandstorm.

Even aside from the not-needing-Sandstorm-integration-per-se aspect, GPG-encrypting all mails "if it has the keys" sounds really promising and simple.  My only concern there are bugs where maybe someone's email is stored as firstnam...@gmail.com and then it's also referenced as firstname.last...@gmail.com -- with the dot -- which isn't picked up by the script, and then a plaintext email is sent.

If there's a setting somewhere which says that all emails to a certain user must be encrypted... well, but the above bug would cause problems here, too.

Actually, for the very sensitive use cases I have in mind, it'd be better to only send the person a passwordless login email if it has their GPG key, else it returns an error saying it can't log them in without their key.

GPG or bust.

The one thing I don't like about that is that it means that *new* users will see the option to log in via email address, and then not receive their email token. In that case, probably you should email them an unencrypted note saying:

"To log in via email token, please communicate with the admin over a safe channel to register a GPG key."

IMHO that is not an information leak since email metadata (From: To: Subject: ) are not encrypted anyway.

 

Personally, I like that because it means that we aren't a showstopper for this tool working; you can create it and document how to integrate it without waiting for us to do anything.

What do you think?

I really think this sounds amazing and I'm going to work on this ASAP.  You said people at Tor want this, too?  They probably have about the same use cases in mind as I do...  If there's any more info you can pass along there related to who I should contact or what stage they're at with Sandstorm or whatever, please send me an encrypted email.  You can import my key with this command:

$ gpg --keyserver pgp.mit.edu --recv-keys 0x3F8AA1E2

http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html

Collisions on 32-bit key IDs are a practical attack. I have two GPG keys with key ID 70096AD1, generated as a second preimage collection. You shouldn't use short key IDs, if you can avoid it. Long key IDs (64-bit) are drastically safer, and full fingerprint is much much safer.

Anyway, can-do.

 

set SMTP_URL in Sandstorm

Are you talking about the setting one set in the web UI as the admin of a Sandstorm server?  Or can this be set as env var, or some other option?  Thanks!

I mean the one set in the web UI, yes.

Cheers!

[Steve Phillips]

Yes - then relay it to SendGrid/Mandrill/etc. That's what I mean! Glad that concept came through, even if by you creating it separately from me.

:-)

GPG or bust.

The one thing I don't like about that is that it means that *new* users will see the option to log in via email address, and then not receive their email token.

If what you have in mind is a "regular" Sandstorm installation but with a bit more security, then I see what you're saying, but for the kind of installation I (and probably the Tor people) have in mind is more like -- I set up a Sandstorm server that's only accessible over Tor, and for people to log in they need to send me a message over email or encrypted IM.  I'm about to do that to hand out CrypTag API keys, but I'd love to give users a fuller Sandstorm experience!

In that case, probably you should email them an unencrypted note saying:

"To log in via email token, please communicate with the admin over a safe channel to register a GPG key."

IMHO that is not an information leak since email metadata (From: To: Subject: ) are not encrypted anyway.

@kentonv has described the future GPG login scheme as one where users "log in by proving they own the corresponding private key."  Regardless of how high or low priority this feature is, have you considered letting users upload a public GPG key without proving that they own the private key?  Then on the login page there could be an expandable "Advanced" toggle near the "SEND LOGIN EMAIL" button where people could upload their GPG key.

Yes, people could insert someone else's pubkey to send that person a bogus email, but they could do that right now anyway, but putting in their email address directly.

http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html

Collisions on 32-bit key IDs are a practical attack. ...

Anyway, can-do.

Fair enough!  I have attached my public key doubly-encrypted with your public key.  See pubkey-steve-ttba.txt.asc.asc, attached :-D.

set SMTP_URL in Sandstorm

I mean the one set in the web UI, yes.

Cheers!

Perfect, thanks Asheesh!

--Steve 

[Steven Phillips]

It's aliiiiiiive!  I've created an early version of this GPG-encrypted mail server thingy, which I'm calling "SecureMailer": https://groups.google.com/forum/#!topic/sandstorm-dev/RuiDPGq6UZ0

Thanks for the pointers, Asheesh!