Modelling File System Permissions Using SAFE Network

API
1

Permissions / Access control for SAFE NFS or more generally for MD and ID types.

I’d like to understand the current and likely future capability and limitations for use of permissions to provide granular access to resources, for example SAFE NFS style files.

Motivation
My motivation is to implement access control for a mapping of files and directories that models a conventional file system hierarchy with granular permissions. The use case is to emulate the Solid REST API within a client library that implements Solid functionality using the SAFE DOM API.

Typically, a conventional Solid HTTPS server achieves permissioned access for individual WebIDs which represent individuals and groups, where different access rights can be granted to containers (directories) and resources (files) by storing access control information to each container and file in a corresponding access control file (one for each container and file with non-standard permissions). This can’t be emulated within the client because any client side access control can be circumvented, so all access control must be achieved using the features of the SAFE API.

I’m trying to discover the degree to which this is possible, and how to achieve it, so any information or comments that would help this would be appreciated, beyond what I’m actually asking for at this stage. Thanks!

Here’s what I think I understand (or assume!) - apologies for errors, please correct as needed:

  • for a Mutable Data object permissions may be specified to (ref):
    • grant or deny any combination of Insert, Update and Manage Permission to Anyone, or one or more public keys (which must be shared outside the API to provide access to account holders or apps)
    • permissions can be granted or denied to one or more public keys

Questions
Q1: can I set permissions for an entry in a Mutable Data, or only for the whole container? Reading the following suggests that the authenticator enforces a more granular than a whole MD, so I’m curious if this is correct and whether or not this is available for any MD or just this specific case:

In order to gain access to a specific name in there, the app may request access using the _publicNames/${publicName} (though that doesn’t directly exist in the root directory). The Authenticator, when finding a request for a container starting with _publicNames/ must prompt the user about whether access should be given to that particular public name. Any request for more than the BASIC permissions as defined above, should be guarded through a double confirmation mode by the user.

Ref: https://github.com/maidsafe/rfcs/blob/master/text/0046-new-auth-flow/containers.md#dns-containers--publicnames

A1: ???

Q2: Does or will the API provide a similar permissions mechanism for Immutable Data, and if so any guidance on this capability?

A2: ???

Q3: Are there any features planned or current that will further assist modelling a permissioned file system, with granular access to individual entries (within an MD) or Immutable Data?

A3: ???

4 Likes
2

Me too.

https://www.kernel.org/doc/Documentation/filesystems/fuse.txt

"‘default_permissions’

By default FUSE doesn’t check file access permissions, the
filesystem is free to implement its access policy or leave it to
the underlying file access mechanism (e.g. in case of network
filesystems). This option enables permission checking, restricting
access based on file mode. It is usually useful together with the
‘allow_other’ mount option."

3 Likes
3

This is not possible at the moment, at least it’s not possible as per what the API exposes, I’ll double check if this has been anyhow partially implemented.

I’m not sure I understand this question, because an ImmutableData cannot be modified, thus I don’t see how these type of permissions would be applicable to the ImmutableData. I presume you are actually referring to the MD that acts as the container (with NFS emulation convention), if so then the question is the same as Q1, am I on the same page?

I’m not aware of any plans but for sure i’s a good idea to try to understand the problem and use cases. I guess we could have permissions granularity to the MD entry level (as you and the RFC seems to imply for the default containers); as far as I understand (and I could be very wrong here in my understanding) each entry mutation is/can be made individually in the network, i.e. with separate requests, so data mgrs. could potentially validate the permissions assigned for an existing entry when an entry mutation request is received…?.
Although what I think it could be problematic is how much space the permissions would take on a MD, i.e. what would be the overhead in the average scenarios, perhaps that’s still ok as it’s the app’s developers/designers choice to use it?. Alternatively I wonder if this could be stored in a separate chunk on the network, but I presume it would most likely be stored by another group adding some other complexities and latency to the process of a single mutation request…

1 Like
4

Thanks Gabriel :slight_smile:

No for Q2 I do mean Immutable Data, but in this case the only meaningful permission would be Read access.

I think entry based permissions would be a big help, so interested to here more about that possibility.

In Solid, they have a default permission (read only for non owner I assume), and then for any resource (file or folder) the owner can specify custom permissions. This is generally implemented by the server creating a “.acl” Access Control List file for the resource, which holds details of what permissions are granted /denied to specific identities (WebIDs). So one “.acl” file for each resource with customised permissions.

My problem is there’s no way for me to implement this client side - same for anyone trying to mimic files system permissions - using the existing SAFE NFS permissions mechanism, I think it would be good to try and provide ways of increasing this capability within the API.

Thanks again.

1 Like
5

I’m a little confused because I thought the DataMap would normally be stored as a mutable data, but here it shows immutable_data::create()…
https://github.com/maidsafe/safe_client_libs/blob/92a7a958746ca14f29a99d08e401b12502a8392c/safe_core/src/nfs/data_map.rs

Any thoughts with regard to the NFS where you have a Datamap that is put on the network as an immutable data and how you manage read access to it? Simply share the decryption key? Leave it clear text as a public immutable data? Is it safe to assume that if one saves an immutable datamap to the network in clear text it will still end up being encrypted by the data managers before being sent to a vault? (This is also somewhat related to our indirection conversations on the other forum. (Data Density Attack - #25 by tfa - Development - Autonomi Forum (Safe)))

1 Like
6

Other thoughts:
When it comes to ownership, my thinking is rather simplistic on the matter rather than looking at it from the perspective of a detailed set of ACLs. All I’m trying to mimic is “chown user:group some/safenfs/path” and “chmod 754 some/safenfs/path”. Not sure if it’s accurate to call this “posix compliant” but this is the perspective from which I’m looking at things. The user:group way to organize things is nice because one could have a ‘friends’ group or a ‘family’ group and associate it with a directory or file to facilitate sharing. Of course this also requires that I mimic ‘useradd’ and ‘groupadd’ functionality etc. I found some good discussion on this here.

Any other updates/insights/suggestions would be helpful.

1 Like
7

Changing the Read permission on an ImmutableData would mean creating a new one after re-encrypting it with a different key (or encrypting it for the first time if it wasn’t encrypted), and that would imply a different xorname/address, so I’m no sure this can be seen as changing Read permission, specially because at the moment you cannot remove it so once it was published with “read” permissions for an app it will stay as readable for that app as long as it keeps the key to decrypt it.

Sharing such a key to decrypt the content has to be done out of band (at least at the moment), and I think it also applies to what @jlpell is mentioning around the possibility of having a group.

So to mimic a group you’d need a protocol to share the encryption key with the apps that belong to this virtual group, and if you need to remove an app from the group the protocol should also allow you to be able to re-encrypt the content with a new key which is shared with all the members of the group except for the ones you are virtually removing from the group. I guess one way to do it is that each app which can be added to these virtual groups can publish an inbox where it can receive updates for the encryption keys, I’m sure there are other ways, this is just what came up to my head now.

2 Likes
8

Thanks for thinking about immutable data - useful to get that understanding.

Having thought a bit more I think it is possible to achieve granular permissions for individual files now (or rather access to them via the MD entry), but much harder to implement (and test!).

Permissions on MD entries gets my vote atm. :slight_smile:

Without that, you could provide an NFS style API that mimics the current system, but looks like one giant MD. Hidden underneath would be a bucket of MDs, one for each unique set of permissions, and all the files with identical permissive would be kept in the corresponding MD. Changing permissions on a single file would clear its entry in the existing MD and move it to the one with the required permissions, creating a new MD as required. I don’t like to think too hard about how to implement this because my head hurts when I try :stuck_out_tongue:

We already need something like this to make it easy to handle containers that overflow a single MD, so perhaps whoever writes that could consider this issue at the same time.

3 Likes