jimpick_ has quit [Read error: Connection reset by peer]
jimpick_ has joined #sandstorm
strugee has quit [Ping timeout: 245 seconds]
strugee_ has joined #sandstorm
cwebber has joined #sandstorm
cwebber has quit [Ping timeout: 264 seconds]
<timmc[m]>
Basic question: If I send out a sharing link and someone uses it to interact with a grain while logged in, and then I delete that sharing link -- do they lose access?
<timmc[m]>
From some experimentation, it looks like they do lose access.
<timmc[m]>
This is a little awkward, because I may want to delete a sharing link that has gotten out onto the public internet but not kick out everyone who has already joined.
<ocdtrekkie>
Yeah I think that is a trait of a capability, people who have it can use it, and if you revoke it they can't use that capability anymore.
<ocdtrekkie>
It'd be nice to have a way to issue a link that grants individual capabilities to each person who uses it or something similar though.
<Corbin>
Hm. I wonder if there's a logarithmic algorithm. The obvious algorithm is linear: use the current cap to ask everybody for a renewal cap, which is just a callable that will be invoked with the new cap. One renewal for each person.
<Corbin>
But if there were a way to roll up those renewals, then I bet that there's a version of the "traitor tracing" technique which could issue a logarithmic number of renewals to a logarithmic number of people, tracking whoever is leaking it with each renewal.
<Corbin>
ocdtrekkie: Tangent with the current #erights discussion, URLs themselves might sometimes be capabilities, so this is a standard case of attenuation.
<ocdtrekkie>
I think the sharing URL is essentially the capability in question for Sandstorm.
<ocdtrekkie>
I'm not presently in #erights because 99% of the time, that stuff goes right over my head.
<Corbin>
It has certainly become...a place with words, yes. But all we're talking about is the ease with which things can be composited together. A URL doesn't exactly lead to more URLs, but sometimes it does.
<timmc[m]>
Or if there were a way to say "hey, everyone who currently has access via the sharing link I made? upgrade them to direct access from me"
<timmc[m]>
I don't think there's even currently a UI way to tell how someone has access. (It says "added by timmc" but doesn't say how.)
<isd>
Yeah, more stuff to add to the grain settings page.
<isd>
Right now I'm kinda banging my head against the test suite failures, and another bug that I was working on until I discovered that the relevant tests were failing for other reasons...
<isd>
I discovered that we call zip synchronously when taking backups, which means you can hang the backend by making a grain that is very large and then taking a backup. I would consider this a vulnerability if we currently made strong (or any) claims about performance isolation, but we don't and I'm pretty sure it's been publicly discussed that it's possible to launch a fork bomb from inside a grain.
<isd>
All of this being a massive detour from trying to optimize disk access for app storage in the hopes that it will help startup times for dynamic languages.
<isd>
I should open a proper ticket for that bug.
<ocdtrekkie>
Is #249 relevant?
<isd>
Possibly, good find. I will have to look at it more carefully.
<isd>
It is not obvious to me that #249 is in fact relevant. It looks like then it was failing on the group, not the user. And it's the same in both places, so...
<isd>
I'm going to factor out the shared code anyway though, just as a cleanup.
<ocdtrekkie>
It seemed like the same error message referring to code in the same file, and that seemed very interesting. I do not understand the code though.
<isd>
Indeed, I have no idea what the original fix actually did.
<isd>
But, it looks group related, and this time it's failing on the uid file (whereas before it was the gid)
<isd>
ocdtrekkie dug up 249 as an issue where we were getting a similar error on the next line.
<ocdtrekkie>
Also, is it notable just above about randomizing the uid and gid in dev mode?
<ocdtrekkie>
The tests run in dev mode, I believe, whereas without that block of code, they are 1000 and 1000.
<kentonv>
I don't have any ideas here
<isd>
The apps are not running in dev mode during the tests
<ocdtrekkie>
Mmm, you are right. I equated dev mode with a dev install.
<isd>
Yeah. Also, I don't have these problems on my local dev install, only when running the tests
<ocdtrekkie>
And the "privileged sandbox vs userns sandbox" thing referred there wouldn't have anything to do with it?
<ocdtrekkie>
I acknowledge a high likelihood half or more questions I am asking are stupid questions, but I am hoping at least one of them ends up useful.
<isd>
If it were just that we'd be seeing this in prod too; most systems are using user namespaces
<isd>
By all means.
<ocdtrekkie>
Which one are we using in tests?
<isd>
User namespaces
<isd>
Wouldn't be getting to that code path at all otherwise, and you need root for the other one
<isd>
(which, side note, I am slightly uneasy about the fact that we don't have any automated testing of the privileged sandbox)
<ocdtrekkie>
Yeah I was just wondering if a less frequently used way of doing things was for some reason being used in tests. But I see the else for what to do if root.
<ocdtrekkie>
So it's trying to write to a thing in the file system but can't. Is there a way to look at that thing at some point and see what it's permissions are?
<ocdtrekkie>
Everything in Linux is a file... right?
<kentonv>
this is a special file that you have to write to when setting up a user namespace. It's weird that it wouldn't be writable, in code that worked fine in the past.
<isd>
kentonv: do the tests still pass on your machine? Or are you now getting the ~19 failures too?