Rainbow/DataStore Access: Difference between revisions
< Rainbow
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
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 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 |
* 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# |
* 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# |
||
| Line 24: | Line 24: | ||
* Sugar Shell invokes read_file() |
* Sugar Shell invokes read_file() |
||
* When read_file() returns, the DataStore sets permission 600 on somefile.doc and/or unlinks. |
* 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...) |
|||
* Two activities need read-only access to the same file, at the same time |
|||
* The datastore gets a write request while another activity is read-only-ing the same file. |
|||
Revision as of 19:04, 5 November 2007
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...)
- Two activities need read-only access to the same file, at the same time
- The datastore gets a write request while another activity is read-only-ing the same file.