Skapp Permissions + SkyDB

We’re about to roll out a feature called SkyDB. More on that will be available very shortly. One thing that I don’t feel like we’ve fully figured out is Skapp permissions.

SkyDB gives each user a filesystem. Skapps can modify individual files within the user’s SkyDB filesystem. Without any security, any skapp can read and modify any file, which creates vulnerabilities if users go to malicious skapps.

We can solve this by creating read access and write access permissions. So basically, a skapp can read from user files if the skapp has received read permissions on that file. And a skapp can write to specific files if the skapp has received write permissions on that file.

This system seems okay, but there are open questions:

  • How does a skapp get permissions on a file? Do we prompt the user?
  • How do we store the permissions list? (using SkyDB to do this seems pretty obvious)
  • How do we distinguish between different updates of the same Skapp?
  • Should the skapp get files/folders that it automatically has permissions for?

Ultimately, it will come down to the client and/or the portal to enforce permissions on the skapp. Basically, if a skapp makes a read or write call to a file, the client/portal needs to block that call if the skapp does not have permissions over that file. And the goal is to make these permissions as painless as possible for the user. The user should be prompted as few times as possible throughout the experience of using many different Skapps which all generally want access to eachother’s data.

note: a Skynet client (say an upgraded version of the Brave browser) can enforce these things independently of the portal. But for normal browser users, the portal needs to be trusted to enforce these permissions.


Wondering if the community has any thoughts on this.

1 Like

@Taek

Hoping it may help in any ways…

How does a skapp get permissions on a file? Do we prompt the user?
It would make sense to me to initially prompt the user for Read/Write permissions from X Skapp (I also imagine including the app ID would help verifying its authenticity).
Maybe it would at the same time be interesting to offer the option, on the very same prompt, to subscribe to the service (Cost/month and or offer a free 15 days trial ?).

How do we store the permissions list? (using SkyDB to do this seems pretty obvious)
I would tend to think the permissions list should be parent of -I would imagine- the private, public and team folders?
When the appropriate folder (private,public,team) is determined by the Skapp or user, the Skapp creates a folder with its stored content inside and permissions list will reflect the changes.

How do we distinguish between different updates of the same Skapp?
Maybe have a unique Skapp ID followed by incremental numbers?

Should the skapp get files/folders that it automatically has permissions for?
I think I answered it ^

1 Like

Right now I’m thinking like this:

Tracking Permissions

Each application will include in its metadata a list of ‘folders’ that it wants to access. There are two classes of folders: public/ and private/. So for example SkyTube in the headers might specify WRITE: public/SkyTube/ and WRITE: private/SkyTube and READ: public/SkynetIdentity.

So the portal/browser would do a lookup for the user in permissions/SkyTube and check if the skapp has all the permissions that it is requesting. This is a bit of an optimization, it allows us to see if the permissions exist before the user is actually making use of them.

Skapp Updates

Developers like to update their applications, which changes the identity. So inside of the permissions/SkyTube file we could also keep a list of keys for developers that control SkyTube. As long as the skapp is signed by the right keys (signatures put in the header of the skapp), then we accept the skapp regardless of whether the link has changed.

1 Like

Okay changed it up quite a bit last night because we are nearing the deadline for SkyDB and I didn’t think the above was actually good enough.

So what we’re doing now is defining files as having a type. The ‘type’ is approximately equivalent to a version number, and it’s a 1 byte field meaning we have 255 potential types and then the ‘0’ type (to indicate an error).

type fileID struct {
    fileOwner     cryptoPubKey
    applicationID string
    fileType      uint8
    filename      string
}

Any change to the application ID or fileType will result in a different identifier for the file, which means you are effectively pointing at a completely different file altogether.

fileType ‘0’ will be invalid, fileType ‘1’ will be “public, unencrypted”, fileType ‘2’ will be “private, encrypted”

1 Like

For permissions, we’ll probably have each skapp have a list (stored on SkyDB) of applications and file types that it is allowed to read and a separate list for file types that it is allowed to modify.

1 Like

Sorry if I’m misunderstanding, but I feel like these statements conflict:

The ‘type’ is approximately equivalent to a version number, and it’s a 1 byte field meaning we have 255 potential types and then the ‘0’ type (to indicate an error).

and

fileType ‘0’ will be invalid, fileType ‘1’ will be “public, unencrypted”, fileType ‘2’ will be “private, encrypted”

So in the first you state that the file type defines the version number? And that you can have 255 different versions under a single application.
But in the second on the filetype defines if it’s private or public? So if you had version 2 of a private application how would that work? Is it evens and odds? I don’t get why two separate properties would be grouped under one variable.

1 Like

Could we maybe get security groups for Skapps so permissions do not need to be assigned explicitly but rather derive them from the groups facilitating a more role-based access control model?

1 Like

That is not something I had previously considered, definitely sounds like it might be a good idea.

1 Like