source: TI05-delivery/trunk/doc/ndgaccess_proposal.txt @ 937

Subversion URL: http://proj.badc.rl.ac.uk/svn/ndg/TI05-delivery/trunk/doc/ndgaccess_proposal.txt@1397
Revision 937, 2.2 KB checked in by spascoe, 14 years ago (diff)

A proposal for storing access control information in .ndgaccess files is included for consultation.

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