Dynamic roles

[mitar]

It seems that currently apps can have only static roles defined. It would be great if app could propose some default roles, but that the user could define their own roles for the app, using their own lists of permissions. (App would still define a static list of permissions.)

[zarvox]

Can you give a motivating example for why this is useful? I have a hard time seeing what dynamically-defined roles atop static permissions give you, since if your permissions are static, your possible roles are the powerset of your permissions.

[dwrensha]

@zarvox: our UI currently does not provide a way to assign an arbitrary subset of permissions. I believe that's exactly what @mitar is asking for here.

[ocdtrekkie]

I imagine there are permissions that only make sense when couple with other permissions. (I imagine a lot of apps not written for a blind drop like capability would break if you gave someone write permissions but not read permissions.) I would think the solution to not having a set of permissions you want is for the app author to add it.

[kentonv]

It has always been my intent that we could add an "advanced" UI where the user can toggle permissions as checkboxes -- with warnings that the app may not actually support arbitrary combinations, so the results are unpredictable.

But yeah, I think it would be very rare for this to actually be useful and I wouldn't want to implement it until we see an actual use case.

[mitar]

So here I am thinking of an app which has native support for Sandstorm and understands the concept of capabilities. So in some way it knows how to respond to user having a permission or not in a sensible way: hiding that part of UI, or showing it, displaying a message about lack of permission, and so on.

I think from Android manifest file approach we learned that there initially, it might seem easier for developers to be able to assume known set of permissions, but in the longer term you want to allow users to be able to disable some permissions for the app. So I would suggest that Sandstorm from the beginning do not promise apps that permissions given to the user would be sensible, but that any permission can be not provided, revoked, and so on (for the user, in this case).

I agree that there might be little use of having blog_edit permission without blog_view permission, but on the other hand for an API endpoint that might be a completely sensible permissions set to provide to a user which will be only submitting new posts. But yes, some default roles should be reasonable. But then owner should be able to rename them, change permissions, remove roles, or add new ones.

In my particular use case, of a voting app, communities have different types of permissions for participants in the decision making process: some moderate, some administer users, some interpret rules, some help make summaries of discussions, some can vote, some can veto. Now, different communities have different rules who can do what, so they should be able to combine these permissions into roles. Why I care about Sandstorm is exactly of the focus on security. I can then say to users that Sandstorm manages all those permissions in one place.

So, in my case part of the process of decision making is to establish those permissions for each grain for each role.

Furthermore, different communities name roles differently. Some have presidents, officers, delegates, some moderators, some managers, some facilitators. Sometimes naming of those roles is a very sensitive subject to a community and it would be great if Sandstorm would respect those sensitives. That the community can select naming for their roles they prefer.

[paulproteus]

Hi @mitar,

I think that the static list in sandstorm-pkgdef.capnp of roles is related to sandstorm-http-bridge. You can get a sense of that by reading src/sandstorm/sandstorm-http-bridge.c++

Specifically, the names of the roles is generated as part of kj::Promise<void> getViewInfo(GetViewInfoContext context) override in that file.

The view info is cached when the grain starts; search the code for cachedViewInfo. Maybe there should be an RPC that apps can do to the supervisor to clear that cache?

Given that, if you implement your own HTTP bridge, or rather, speak the underlying capnproto calls to Sandstorm, then you can change what appears in that drop-down. I believe the logic is embedded in the UIView that the app returns; see:

sandstorm/src/sandstorm/hack-session.capnp

Line 72 in 432be37

getUiViewForEndpoint @8 (url :Text) -> (view :Grain.UiView);

With the above, is it important that sandstorm-http-bridge incorporate that functionality? Honestly curious what you think.

[mitar]

Can this work besides HTTP bridge? Can I say to the HTTP bridge, do not provide any roles, and that I do not have to provide any roles through the pkgdef.capnp file, but that my app will connect to Sandstorm and instruct it what roles to provide in the dropdown?

The question though is, what happens if my app changes roles but some users are assigned now removed roles, for example?

[mitar]

So I do not think that there is need for HTTP bridge to really provide this, but there should be then a bit more documentation how you get to talk to Sandstorm from your app. It seems obvious to all you, but I am pretty lost. (Probably because I do not even a way to get session ID in Meteor.)