Rainbow/DataStore Access

This page is a brain-storm page discussing how to implement the two basic access mode of the DataStore: read-only and write

To prevent excessive copying of files, the datastore should have a way to provide access a specific file in the store to a specific instance of the Activity. We need some user-id group-id setup for that:

All groups and users are the normal unix /etc/group and /etc/passwd users. Because we are going to be writing to them a lot, we need a locking mechanism!

• All installed activities get their own group called 'ActivityName', this will be used for file permissions per-activity settings (this ignores name clashes...)
• All activity instances get their own UID and GID. These will be between 10000 and 20000 and should for simplicity always MATCH. Unix requires names for users and groups, lets call them 'ActivityNNN' where Activity is the ActivityName (first 3 letters) and NNN is the UID#

Read-Only

Example: 'Write' needs access to a document during load:

• The Sugar shell creates UID/GID 10001 for the instance, and updates 'WriteGroup', adding Wri10001 to the WriteGroup
• The DataStore creates the tree:

user.group permissions file: 
olpc.olpc 755 /ds
olpc.Wri10001 750 /ds/<instance-uid>/
hardlink: ln /home/olpc/..../file-in-ds.ext  /ds/<instance-uid>/somefile.doc 
olpc.Wri10001 640 /ds/<instance-uid>/somefile.doc

• Sugar Shell invokes read_file()
• When read_file() returns, the DataStore sets permission 600 on somefile.doc and/or unlinks.

Problems to solve

• Clean up, this needs to be periodic / at startup (crashes happen...)
  • Cleanup can be done by a cleaner-process that is forked off every few activity launches.
• Two activities need read-only access to the same file, at the same time
  • This can be handled by controlling access at the gate-dir and providing read access via the 'other' bits.
• The datastore gets a write request while another activity is read-only-ing the same file.
  • This is a bit ugly. A correct solution is to manually break the hardlink by having the DS copy the file to a new name, deleting the old link, then moving the copy into position.
• Concurrent writes.
  • Since we want to avoid API changes to the DS, we could tell activity authors that they need to do proper locking when writing using, e.g. POSIX 'flock() and lockf()'.