[_CD6_]<alpine>Doc>EarlyDesign>6-10-81.minutes!1

RPC and authentication. If RPC is going to be "done right", then a (perhaps optional) part of the process of establishing a remote interface is to authenticate both parties involved. It follows that RPC can provide us with the (authentic) identity of the client who has created a particular remote instance of FileStore. If for each remote instance of FileStore RPC NEWs and STARTs a module on the server, then the client identity can be a parameter to this module. This means that the client identity does not need to be passed as an explicit parameter to each operation that requires access to it.

It may be the case that we allow Alpine access to only a subset of the clients that are known to Grapevine. If this is true, we plan to perform the check during the process of STARTing the module on the server side of the connection. If the client is not allowed access, we immediately inform RPC of the fact, and RPC can shut down the module and reclaim the space.

Access control lists. Because the Grapevine R-server database must fit onto a pair of Alto disks, Grapevine does not encourage clients to construct RNames (there is no GenSym for making new unique RNames.) The theory is that any grapevine client that stores RNames should be prepared to store lists of RNames. So according to this theory we must be prepared to associate a small number of lists of RNames with each file (for read and write access control.)

It seems clear, however, that file system customers will want to create ad hoc logical groupings of RNames for access control purposes, and that these groups are not logically associated with a single file (i.e. a collection of related files are often equivalent in protection status, and we want the ability to give a single person access to the collection by adding the person to a group rather than enumerating the collection.) Hence storing the members of a group, rather than the identity of the group, with a file is a mistake. It is also clear that these groupings are not even logically associated with a single FileStore.

My personal view is that we should invest no effort in this area, and instead encourage the development of larger-capacity registration servers more suited to the needs of file access control but fully integrated with the Grapevine facilities. Even if no work goes into improving Grapevine (but a small number of new lists added for the purposes of file access control), wouldn’t a single-RName access control scheme still dominate the present IFS facilities?

Space accouting database. Karen produced a memo that dealt with the structure of this database and its implementation. The design gives higher concurrency than a general-purpose database implementation is likely to; for instance, it allows the same owner to create files in different concurrent transactions with minimal conflict. This is achieved by aggregating the net change in space allocation for an owner due to a transaction and writing a single log record reflecting the change during phase one of commit. This is an "application level" log record, processed in recovery only after the FileStore is made transaction-consistent with respect to file-level actions. The actual database update is performed after the transaction commits; hence no undo of these updates is ever necessary.

We noted that it is difficult to maintain a complete isolation between concurrent transactions that allocate space for the same owner. Our policy will be to "charge" a client for space from the moment it is requested (before the request is committed) until the moment it is released and the release is committed.

Other owner-based databases. Karen’s memo discusses other databases keyed on owner. Here I simply note that while the space accounting database is (at least plausibly) associated with a single FileStore, it may not be wise to fragment other such databases in this way. If they are really distributed databases then there is no avoiding the fact. The only thing resembling a distributed database system that we have access to is the Grapevine registration database. This may be suitable, e.g. to store the database of who is allowed to create files for a particular owner. The forthcoming directory system (which I think Gifford will produce) will be a second distributed database system.

File-based databases (including "leader page"). There is general agreement that the implementation of "file properties" should hide the fact that some of them are stored in a file leader page.

Just what belongs in the leader page is still an open question. Our previous discussion of this topic emphasized the notion that any file property that is essential to the interpretation of the file should be stored in the leader page, so that destruction of the property will likely imply destruction of the file. I suggested that the "essential" properties are: version number, create date, string name (for directory system), byte length, and RNames for owner, access-changers, readers, and writers. The "less important" properties are read date, write date, whatever other information is kept for backup and archive purposes, and user-defined properties.