| 1 | The Problem: |
|---|
| 2 | |
|---|
| 3 | How do you prevent the bbftp server deliverying a file to a user for |
|---|
| 4 | which he doesn't have permission as defined in the MOLES/CSML |
|---|
| 5 | document referencing the file? |
|---|
| 6 | |
|---|
| 7 | The key point is that the permission information isn't stored with the |
|---|
| 8 | file and there isn't an obvious way to get from the file to the |
|---|
| 9 | referencing CSML document. |
|---|
| 10 | |
|---|
| 11 | I propose to solve this by creating access control files (called say |
|---|
| 12 | .ndgaccess) within the dataset's directory structure that reflect the |
|---|
| 13 | CSML security conditions. These files would effectively be a |
|---|
| 14 | filesystem cache of the security conditions on each file/directory. |
|---|
| 15 | Creating and updating .ndgaccess files could be done by tools that |
|---|
| 16 | take the CSML document as input. This allows the bbftp layer of the |
|---|
| 17 | DeliveryService to operate without any knowledge of CSML. |
|---|
| 18 | |
|---|
| 19 | Proposed algorithm: |
|---|
| 20 | |
|---|
| 21 | Access to each file is controled by the "nearest" .ndgaccess file when |
|---|
| 22 | traversing up the file's path. Therefore for file |
|---|
| 23 | /foo/bar/baz/data.nc we would search for .ndgaccess files in the |
|---|
| 24 | following order: |
|---|
| 25 | |
|---|
| 26 | /foo/bar/baz/.ndgaccess |
|---|
| 27 | /foo/bar/.ndgaccess |
|---|
| 28 | /foo/.ndgaccess |
|---|
| 29 | /.ndgaccess |
|---|
| 30 | |
|---|
| 31 | Once an .ndgaccess file is found the search stops. |
|---|
| 32 | |
|---|
| 33 | I think .ndgaccess files should not just duplicate the Allow/Deny |
|---|
| 34 | structure of dgSecurityCondition in order to make them efficient to |
|---|
| 35 | parse and to emphasise their role as subordinate to the CSML. |
|---|
| 36 | Perhapse something as simple as <file>:<role>:<permission>, for |
|---|
| 37 | instance: |
|---|
| 38 | |
|---|
| 39 | # Default for all files |
|---|
| 40 | :superrole:rw |
|---|
| 41 | :role1:r- |
|---|
| 42 | # Per file access control |
|---|
| 43 | file1:role2:r- |
|---|
| 44 | file1:role3:r- |
|---|
| 45 | # File2 explicitly unreadable role1 |
|---|
| 46 | file2:role1:-- |
|---|
| 47 | |
|---|
| 48 | I havn't really thought about the use of write permission yet, let |
|---|
| 49 | alone execution permission (which might be relevant for directories). |
|---|
| 50 | |
|---|
| 51 | One thing Bryan suggests is that we might need an AttributeAuthority |
|---|
| 52 | field. I would expect any one DeliveryService to be acting under the |
|---|
| 53 | duristiction of only one attribute authority and therefore it might be |
|---|
| 54 | superfluous. However, without it the roles are ambiguous outside the |
|---|
| 55 | context of the original DeliveryService. Maybe a declaration of the form: |
|---|
| 56 | |
|---|
| 57 | attrAuthority = <attrAuth> |
|---|
| 58 | |
|---|
| 59 | once in each .ndgaccess file would do. |
|---|
