> explain how it could be more elaborate. it's completely up to them (as it is to fossil or kfs, which use a file /adm/users that they maintain themselves). the location and representation of group membership, and its interpretation are all independent things. that is, all three aspects could be handled by different services: for instance something like google's Chubby could store a group map in s-expression form [unknown to chubby] but read and interpreted by other servers, even with different interpretations of what that representation meant)
as another example, in a flash file system we did for inferno, there wasn't an /adm/users but a ctl file of some sort received requests to manage a group membership similar to fossil console requests. as a further example, SPKI's public key certificates can be used in various ways to establish group membership, typically by producing a certificate stating that a given principal (represented by a public key) is a member of a local name (ie group) rooted at another principal's public key. the latter principal might correspond to the `owner' of a resource. this example is more interesting than some of the others because there isn't (in general) a group membership list; also SPKI itself allows delegation and compound group names. in your case, however, a simple scheme might have the kernel (or just a device) accept a ctl request that added or removed a user name from a local group table, and then system start up script(s) would load the table from some agreed source (and presumably one that's adequately reliable). i think something like that was mentioned, if not discussed, many months ago on the list.
