search

sandstorm-io / sandstorm

Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager.
https://sandstorm.io
Other
6.74k stars 708 forks source link

Shared grains associate with apps by name, not ID #3598

Open ocdtrekkie opened 2 years ago

ocdtrekkie commented 2 years ago

So this one really confused me: I installed @orblivion's experimental Etherpad package, which I knew had a different appId than the official one, and is not an upgrade. You can see this because I now have two Etherpad installs: etherpadbug0

I was really vexed to already have a grain made with it, considering it's a new app I haven't played with before, from 2017 no less! etherpadbug1

Interestingly enough, the same grain also appears in the official Etherpad app's grain list: etherpadbug2

But the official one has grains I created in addition to ones shared with me. Which suggests to me that the grains shared with me are being matched to the app by name, not ID.

It doesn't offer to upgrade the grain or anything since it's not my grain, and it loads it in the correct version for whoever owns that grain, but it doesn't seem like it should appear here.

ocdtrekkie commented 2 years ago

It does occur to me that this may be because Sandstorm servers generally aim to obscure appIds and packageIds that other users have installed because they may not be publicly available. So that is something we probably need to bear in mind when addressing this: It's possible the solution would be worse than the problem from a security standpoint, and the likelihood normal users would have two apps with the exact same name is probably slim.

orblivion commented 2 years ago

So I'm getting something a little weirder. I have two current-etherpad grains. When I look at current-etherpad app page, they show up as mine. When I look at the experimental-etherpad app age, they show up as shared. I don't think I have other users making grains on my server. I'm fairly sure I'm the human that made these two documents, at any rate.

On Fri, Jan 7, 2022 at 5:08 PM Jacob Weisz @.***> wrote:

It does occur to me that this may be because Sandstorm servers generally aim to obscure appIds and packageIds that other users have installed because they may not be publicly available. So that is something we probably need to bear in mind when addressing this: It's possible the solution would be worse than the problem from a security standpoint, and the likelihood normal users would have two apps with the exact same name is probably slim.

— Reply to this email directly, view it on GitHub https://github.com/sandstorm-io/sandstorm/issues/3598#issuecomment-1007774859, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAKH6FPU5AOL525RNGN3KDUU5P4BANCNFSM5LPXKHMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

zenhack commented 2 years ago

Another data point that may be related (that I've been meaning to report as a separate bug, but I'm always on my phone when I notice it): I have a separate account that I log into on my phone, since I don't trust my phone as far as my computer. On that account, I have sandcal & prioritize grains I shared from the main account before I'd actually made icons for those apps -- and on the phone account the icons for those grains show up as the auto-generated thing for apps with no icons still. So it definitely seems like we have some problems with getting app info for shared grains.

orblivion commented 2 years ago

I had a hypothesis - these two Etherpad grains that show up as "shared" for me were created on Oasis and mass-transferred to my current server. Perhaps this puts it in a state that this list considers it "shared"? BTW one of them has a "was: " in this view. Per my hypothesis it would have been the name on the original server.

I just tried duplicating it by creating a new sandstorm server and mass-transferring an etherpad grain. However, the mass transfer feature doesn't seem to be working. Filed #3599

orblivion commented 2 years ago

(I did an inspect-element to change the file names) etherpad-1 etherpad-2

kentonv commented 2 years ago

I think this is intentional. The idea is that we want to encourage people to hack on their apps and run modified versions. We don't want it to be the case that if one person happens to use a modified Etherpad, then no one else can find the documents that person shared because they don't show up under their own Etherpad install.

To that end, I think we group shared documents by app title.

ocdtrekkie commented 2 years ago

I can see that logic. Any idea what could cause Dan's example, where the grains show he owns them under one view, and that they're shared under another view?

ocdtrekkie commented 2 years ago

I'm removing the bug label since Kenton thinks the functionality we opened the issue for is by design.

kentonv commented 2 years ago

Any idea what could cause Dan's example, where the grains show he owns them under one view, and that they're shared under another view?

Ah, that part seems like a bug. Probably what's happening here is that sometimes a grain you own also appears in the list of grains shared with you, because somehow you shared it with yourself (or maybe owned grains are always shared with oneself, I'm not sure). But on the client side, when we construct the list of grains for an app, we merged the list of grains you own created with that app (filtered by app ID) with the list of grains shared with you that were created by any app with the same title. We then de-dupe, so a grain that is both owned by you and shared with you will only appear as owned by you. But if the grain is owned by you but created with a different app with the same title, then it only appears in the "shared with me" list and doesn't get de-duped with anything, I suppose.

ocdtrekkie commented 2 years ago

That is such a niche bug case I am having a hard time wrapping my head around how to rename this issue to reflect it.

ocdtrekkie commented 2 years ago

I think we should just leave this issue here as an informational testament to both the intended behavior and the weird edge case that is probably way too niche to spend time and effort fixing.

orblivion commented 1 month ago

Jacob suggested that we don't want the app ID of a shared grain to be leaked, in order to hide secret apps. Fair enough. But what if I get a grain shared with me and I already have the given app installed? Then the app itself is not a secret to me. So then, would it be appropriate to let me know that "this shared grain is running this app"? vs "this grain is running a different app of the same name which may or may a different version of the same app or a different app altogether"? This would leak the fact of some other app or version of the same app, but nothing more about the app. (Of course the user can actually use this secret app in the grain they've been given access to)

If that's an okay piece of information to leak, maybe we could improve the UX by saying so. Maybe by putting those shares in a different section of the lists. That way we'd reduce confusion.

Now, if that's okay, I'd have a subsequent question: Could we leak the distinction between "this grain belongs to a different version of the same app" and "this grain belongs to an app of a different id"? Perhaps the reason to not leak this is that it might be a secret that the app is being upgraded? (Though, if you're being given the share and you notice something different, the secret's out anyway).