<kentonv>
ideally security bugs should probably be reported to security@sandstorm.io rather than in public...
<ill_logic>
And then when I try the link instead of the code, I get a 403 with:
<isd>
Yes. This one is out of the bag now though, so...
<ill_logic>
"To confirm your email address, you must be logged in as the account that created this link." - but I'm trying to log in in the first place
<kentonv>
BlueNinja, I'm unable to reproduce. When the owner revokes the link, the guest sees "you do not have permission to access this grain [request access]"...
<BlueNinja>
let me reproduce it again.. one sec
<kentonv>
BlueNinja, are you sure you're not logged in as the same user in both browsers? Only the grain owner should ever see a "restore from trash" button...
<BlueNinja>
nope. separate gmail accounts
<BlueNinja>
and i chunked the 2nd accoutn down to visitor after i was in, too.
<BlueNinja>
ok i see its squirrly.. if it helps it was a collection I shared and one of the grains (etherpad) was the one that I got back into somehow..
<BlueNinja>
onemoment..
<BlueNinja>
I removed ALL sharing access to the collection and the individual grains.. but 2nd user still sees them in the Grains menu.. ofc it does ask to request access, but the user sees them still. is that right?
<kentonv>
yes, the idea is that the user might be confused if the grain disappears entirely from their list. It's less confusing if it's there, but when they click on it, they're told they no longer have access.
<ill_logic>
You folks do one hell of a job making signup frictionless. Even when it comes to putting in payment info.
<ill_logic>
And you respect that people don't always want to put in their street address when they pay for something.
<BlueNinja>
kentonv: cool, gotcha
<kentonv>
ill_logic: I'd love to take credit but that's actually Stripe's UI. :)
<kentonv>
(at least the part where you enter your credit card number -- our servers actually never see it!)
<BlueNinja>
Cant reproduce it yet but I did come across this: 1. create colleciton. 2. add etherpad 3. Share by link as VIEW ONLY to 2nd user 4. Owner go into Etherpad and show who has access 5. Owner kills that specific user's access to Etherpad (not the entire collection) ... result = Owner's collection has a broken etherpad and needs to be readded to the collection
<kentonv>
BlueNinja: Yeah. Let's say Alice is the owner of the collection and the pad, and Bob is the visitor. So Bob opens the collection and then clicks through to the pad. Alice wants to revoke Bob from the pad. But if Bob still has access to the collection, he can follow the link again. So either the link from the collection has to be revoked, or Bob has to be revoked from the collection.
<kentonv>
If you try to revoke Bob from the pad, currently the behavior is that the collection is disconnected from the pad. We'd like to improve it so that it tells you all the options.
<BlueNinja>
oh i gotcha
<BlueNinja>
breaking up the security breaks up the collection
<BlueNinja>
indeed in the "unsaid" but makes sense
<kentonv>
there is a popup message that tries to explain this but the text is *really* confusing...
<kentonv>
we need to make it better
<BlueNinja>
righton
<pdurbin>
isd: kentonv is here and can probably speak to the state of JVM stuff in Sandstorm.
<kentonv>
We managed to get Wave (which is Java) to run in Sandstorm but I've heard other people complain about the JVM being unhappy with missing /proc.
<asheesh>
There's a bunch of hard-won knowledge in there, so I hope I can save someone else the trouble. :)
<BlueNinja>
where's the location of the main index.htm in my on-prem sandstorm?
<BlueNinja>
im poking around in /opt/sandstorm/sandstorm-198 ...
<asheesh>
It's dynamically created by our codebase; to make sense of it, you'll probably need to understand the basics of the Meteor framework and read our source code at https://github.com/sandstorm-io/sandstorm
<asheesh>
Fundamentally, there isn't an index.html ; it's created each time someone requests the page, calculated by Javascript code that we wrote and integrated with Meteor.
<BlueNinja>
oh. I wanted to use that <script> snippet in hummingbird to tell me where users are coming into my sandstorm from ...
jemc has quit [Ping timeout: 245 seconds]
<ill_logic>
Oh sandstorm uses Meteor. I guess that sort of makes sense.
jemc has joined #sandstorm
<BlueNinja>
sandstorm just wants to use outbound smtp right? is there a recommendation for which smtp server to setup that's simple and I can secure/lockdown just for sandstorm?
<BlueNinja>
something I can setup on my Ubunut 16.x where sandstorm is for SMTP outbound only allowing the local IP to access it
<kentonv>
BlueNinja: I suggest using a mail delivery service like Sendgrid, Mailgun, or Mandrill. Chances are your IP address is already blacklisted for outgoing SMTP, sadly.
<kentonv>
where is your server hosted?
<BlueNinja>
linode
<BlueNinja>
cloud *nix server hosting company
<kentonv>
yeah, usually all the IPs at big shared hosting providers are blacklisted. But you could always check...
<BlueNinja>
ok ill check with the RBLs
<TimMc>
Mixed. Here on RCN in Boston I haven't had trouble, but I guess I've only sent test messages...
<kentonv>
or some providers simply block outgoing SMTP so that they don't get blacklisted
<TimMc>
Oh wait, you said hosting providers.
<kentonv>
DigitalOcean seems to do a good job of policing their SMTP such that you can actually use it. I'm not sure how they manage that.
<isd>
linode quite likely will be ok. I've had good luck with leaseweb for my personal mail; been relying on a mailserver on a VPS with them since 2010. I'm using mailgun for sandstorm though, just because I couldn't be bothered to set it up
<isd>
re: mail server software recommendations: I can strongly recommend opensmtpd
<BlueNinja>
nice, ill try that
<BlueNinja>
waiting for RBL check results :)
anthropy has quit [Quit: Leaving.]
anthropy has joined #sandstorm
<BlueNinja>
wow... not listed on all 50+ RBL checks/lists. The captain has turned on the SMTP light. Prepare for outbound.
<isd>
You'll also want to set up SPF & DKIM at least; not doing that is another good way to get branded as a spammer
<BlueNinja>
this is true..
<isd>
dkimproxy is pretty easy to integrate with opensmtpd
<isd>
SPF is of course just a DNS entry
<BlueNinja>
yeah, and I'll look into that dkimproxy
anthropy has quit [Client Quit]
anthropy has joined #sandstorm
ill_logic has quit [Ping timeout: 248 seconds]
<BlueNinja>
as an administrator, is there no way to see other peoples grains they have created?
<BlueNinja>
even if it was just a list of the grain types and how much space theyre consuming?
<digitalcircuit>
I'd also find this useful, especially since there's no easy way to set quotas on self-hosted (even if it can't be as enforced as Oasis is). My current approach is just running "ncdu" (ncurses disk usage) on the Sandstorm directory.
<BlueNinja>
ill try that.. but yea - definitely dont want someone abusing space and over consuming.
<TimMc>
I'd be interested in a soft quotas (warning only) thing too.
nwf has quit [Ping timeout: 240 seconds]
nwf has joined #sandstorm
ill_logic has joined #sandstorm
anthropy has quit [Ping timeout: 248 seconds]
<pdurbin>
isd: did the post asheesh linked to about JVM stuff help? Lots of detail in there. Thanks, asheesh.
<isd>
pdurbin: yes it did; I hit the shared library issue at least. Thanks asheesh
<isd>
Still fussing with it though.
<isd>
(but not all the issues are going to just be Java)
<isd>
There's going to be a bit of actually dev work to do to integrate this as well
<isd>
Are folks at all familiar with what elk stack does? I'm wanting it for dev purposes and am curious to other's input as to what that should look like
<isd>
I'm thinking of just writing a quick capnp schema for exporting the log recording.
<isd>
(as well as whether folks besides me would be interested).
<pdurbin>
I've heard good things about the ELK stack. :)
anthropy has quit [Remote host closed the connection]
aldeka_limechat has quit [Remote host closed the connection]
<isd>
I'm staring at the console output and thinking it would be really nice if I had some tool to help me navigate this more easily :P
anthropy has joined #sandstorm
<pdurbin>
Console output of what?
<isd>
The app
<isd>
I think I've found the problem though
jemc has joined #sandstorm
isd has quit [Remote host closed the connection]
anthropy has quit [Ping timeout: 245 seconds]
ill_logic has quit [Ping timeout: 240 seconds]
anthropy has joined #sandstorm
rolig has quit [Ping timeout: 248 seconds]
rolig has joined #sandstorm
Aurelius has quit [Quit: Aurelius]
Aurelius has joined #sandstorm
aldeka_limechat has joined #sandstorm
aldeka_limechat has quit [Remote host closed the connection]
isd has joined #sandstorm
jemc has quit [Ping timeout: 240 seconds]
aldeka_limechat has joined #sandstorm
isd has quit [Ping timeout: 240 seconds]
jemc has joined #sandstorm
isd has joined #sandstorm
<isd>
So, I think elasticsearch is trying to determine the mountpoint of a directory, and failing because /proc isn't mounted. Have folks hit that before?
<isd>
Suppose I could just overwrite /etc/mtab...
aldeka_limechat has quit [Remote host closed the connection]
<isd>
Is there a way to get spk dev *not* to update the file list at all? elk stack touches a lot of files, and so shutting it down tends to be very slow; I'd like to be able to skip that step during dev.
<isd>
Hrm, okay, that's not it. For some reason /var is 0660.
<isd>
...and not owned by the user the grain is running as/
<isd>
While the notion makes me sad, I find myself thinking it would be useful to be able to put files in the uninhabited /proc, to spoof things like this.
jemc has quit [Ping timeout: 260 seconds]
<mokomull>
isd: I can totally understand where that logic would've come from - I've wasted tons of time debugging /etc/mtab not matching reality.
<isd>
You mean the java source?
<isd>
And yeah, I get it.
<isd>
Though on most linux systems these days /etc/mtab is just a symlink to /proc/mounts
<mokomull>
That symlinkiness seems to have rolled through alongside systemd, though perhaps that's just because of when CentOS 7 and Ubuntu 16.04 were each frozen.
<isd>
I think Arch may have done it prior
<mokomull>
*nod* I think Arch was ahead of the curve for /bin unification, too, IIRC.
<isd>
yeah
<isd>
that I remember.
<mokomull>
There's a reason I keep Arch around as my tip-of-tree development VM.
<isd>
I use it as my main client-side OS
<isd>
Anyway, I'm basically ready to give up on this for now; it's got a hardcoded path to /proc that's throwing an exception. Not sure what I can do without something to let me spoof /proc
<isd>
Might send out a mailing list post
<mokomull>
I suppose the caller from ElasticSearch is similarly not conditional?
<isd>
Haven't dug into it
<mokomull>
What's the stack?
<isd>
Let me get it up again
<isd>
It's rather late for me to be poking through a java codebase for the first time in 5+ years.
<mokomull>
heh, I live in Javaland by day. Can't say I'd recommend it.
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mokomull>
'night
<mokomull>
I'm a little surprised that code path hasn't been hit, but then again, I hadn't ever heard of a FileStore before ...
aeternity has quit [Ping timeout: 248 seconds]
aeternity has joined #sandstorm
harish has quit [Ping timeout: 240 seconds]
harish has joined #sandstorm
xet7 has quit [Quit: Leaving]
Telesight has joined #sandstorm
rolig has quit [Ping timeout: 260 seconds]
rolig has joined #sandstorm
aeternity has quit [Ping timeout: 240 seconds]
harish has quit [Ping timeout: 258 seconds]
demonimin has quit [Remote host closed the connection]
demonimin has joined #sandstorm
harish has joined #sandstorm
demonimin has quit [Remote host closed the connection]
harish has quit [Read error: Connection reset by peer]
demonimin has joined #sandstorm
harish has joined #sandstorm
demonimin has quit [Ping timeout: 248 seconds]
harish has quit [Read error: Connection reset by peer]
harish has joined #sandstorm
jemc has joined #sandstorm
jemc has quit [Ping timeout: 255 seconds]
harish has quit [Ping timeout: 245 seconds]
demonimin has joined #sandstorm
harish has joined #sandstorm
jemc has joined #sandstorm
mnutt has joined #sandstorm
jemc has quit [Ping timeout: 245 seconds]
jemc has joined #sandstorm
NwS has joined #sandstorm
samba_ has joined #sandstorm
jemc has quit [Ping timeout: 258 seconds]
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<isd>
mokomull: I mean, elasticsearch is this scale-out thing that uses many storage devices. I suspect the logic is part of figuring out what to put where or somesuch. I give it good odds it checks for available space next.
<isd>
Not something I expect a typical sandstorm app to do
<isd>
that plus the fact that there are only so many Java + sandstorm things... doesn't seem that unlikely
samba_ has quit [Ping timeout: 260 seconds]
_whitelogger has joined #sandstorm
samba_ has joined #sandstorm
ill_logic has joined #sandstorm
samba_ has quit [Ping timeout: 255 seconds]
<BlueNinja>
is there any move to make sharing easier (e.g. when you start typing a user name,it shows a dropdown of users that narrows down)? Having to know their email address or full username with no helper-list is no fun
<isd>
So, I'm noticing that there does appear to be a /proc/cpuinfo in the grain; how does that get there? was this special-cased to get stuff to work?
<zarvox>
BlueNinja: users that have opened sharing links from you before ("are in your contacts") will be autocompleted in the sharing dialog. Not sure how to bootstrap that without revealing everyone's identities to everyone else.
<BlueNinja>
hmm
<zarvox>
In Sandstorm for Work, you can specify that all users are in each other's contact lists, if you're in a high-trust environment
<BlueNinja>
yea, i see.
<mokomull>
zarvox: Is "revealing everyo"... that actually just exactly answered my question.
<BlueNinja>
so, it does autocomplete for users from your sharelinks.
<BlueNinja>
ok i can work with that..
<zarvox>
Users that have (non-anonymously) opened a sharing link you sent them will show up in autocomplete for you in future invocations of the sharing dialog
<BlueNinja>
right
ragesoss has quit [Ping timeout: 258 seconds]
<isd>
mokomull: finished following through the stack trace; all the way from main() there are no conditionals that would prevent /proc/mounts from being read under any conditions.
<isd>
poop.
<mokomull>
Java: Overly configurable, except for the parts you want to configure.
<isd>
(ignoring of course things that would cause it to barf earlier)
<isd>
sigh.
<isd>
I could just patch the file to change that path if I wanted to build elasticsearch from source.
<isd>
I really don't want to though -- using their .deb is much preferred
<isd>
last I messed with gradle it was unpleasant
<mokomull>
isd: and ironic: immediately below the call to getFileStore() in ESFileStore is a try { getMountPoint() } catch { /* do nothing */ }
<isd>
christ
<isd>
Think I'm going to mail sandstorm-dev re: spoofing /proc
<mokomull>
:( I checked the jdk8 sources just to see if maaaybe that changed since the jdk7 link you posted, and nope.