[9fans] the meaning of group - Plan9

This is a discussion on [9fans] the meaning of group - Plan9 ; for a file on a fileserver, the meaning of group and group permissions is pretty clear. if the user belongs to the group of the file and group permission is granted, then permission is granted. for a device file, the ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [9fans] the meaning of group

  1. [9fans] the meaning of group

    for a file on a fileserver, the meaning of group and group
    permissions is pretty clear. if the user belongs to the group
    of the file and group permission is granted, then permission
    is granted.

    for a device file, the meaning of group is unclear to me,
    as users on a cpu server are determinted by the auth server.
    there are no groups.

    is there any sensible interpretation of the group outside
    a fossil/kfs/ken's fileserver?

    - erik

  2. Re: [9fans] the meaning of group

    > if the user belongs to the group
    > of the file and group permission is granted, then permission
    > is granted.

    ...

    > is there any sensible interpretation of the group outside
    > a fossil/kfs/ken's fileserver?


    it's just the same: is the user a member of a given group or not?
    how membership is established is up to the file server.
    the kernel's scheme is trivial (although it could be more elaborate)
    but that doesn't limit what other file servers do.
    as with the examples you mention, they have only to implement it.


  3. Re: [9fans] the meaning of group

    >
    > it's just the same: is the user a member of a given group or not?
    > how membership is established is up to the file server.
    > the kernel's scheme is trivial (although it could be more elaborate)
    > but that doesn't limit what other file servers do.
    > as with the examples you mention, they have only to implement it.
    >


    explain how it could be more elaborate. where do you put the mapping.
    the auth server?

    as far as i can tell, unless a kernel-generated file has permissions like 0064,
    and the owner is eve, the group checking in the kernel doesn't do anything.

    i should explain a bit the context. since we have many folks with a use
    for the aoe device on a few cpu servers, it would be useful to allow, say,
    the fileserver group sys access to /dev/aoe/*.

    - erik

  4. Re: [9fans] the meaning of group

    > 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.


  5. Re: [9fans] the meaning of group

    >
    > 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.
    >


    without any agreed-upon or secure arbiter of groups which tracks centralized
    information, this does not seem like a good idea to me.

    i apologize if this has been discussed before.

    - erik

  6. Re: [9fans] the meaning of group

    > without any agreed-upon or secure arbiter of groups which tracks centralized
    > information, this does not seem like a good idea to me.


    `centralised' information?

    > 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,


    i assume you'd have to be hostowner to load it, so it's up to the host-owner process that loads it what it
    regards as `adequately reliable' data. on a cpu server, it can be consistent with the user names associated with
    processes on that system. that's not centralised though: it's a local convention.


  7. Re: [9fans] the meaning of group

    On Mon Jan 28 18:01:00 EST 2008, forsyth@terzarima.net wrote:
    > > without any agreed-upon or secure arbiter of groups which tracks centralized
    > > information, this does not seem like a good idea to me.

    >
    > `centralised' information?
    >
    > i assume you'd have to be hostowner to load it, so it's up to the host-owner process that loads it what it
    > regards as `adequately reliable' data. on a cpu server, it can be consistent with the user names associated with
    > processes on that system. that's not centralised though: it's a local convention.


    i don't mean coordiated outside our site. perhaps i didn't make that clear.

    what you're saying sounds like, say, putting some configuration in /rc/bin/cpurc.
    the problem is that this information needs to be updated across all cpu servers
    more often than everything is rebooted.

    perhaps a file on /srv/boot could be given to the fs which could be opened to check
    group permission? too cute?

    - erik

  8. Re: [9fans] the meaning of group

    think about what you said. you don't understand the auth model.
    glad to see that you are still replying to everything and generate 40%
    of the traffic on 9fans. i'm with maht. this is not a "i couldn't be bothered"
    blog. yes, this is not a love song...

    brucee

    On Jan 29, 2008 10:35 AM, erik quanstrom wrote:
    > On Mon Jan 28 18:01:00 EST 2008, forsyth@terzarima.net wrote:
    > > > without any agreed-upon or secure arbiter of groups which tracks centralized
    > > > information, this does not seem like a good idea to me.

    > >
    > > `centralised' information?
    > >
    > > i assume you'd have to be hostowner to load it, so it's up to the host-owner process that loads it what it
    > > regards as `adequately reliable' data. on a cpu server, it can be consistent with the user names associated with
    > > processes on that system. that's not centralised though: it's a local convention.

    >
    > i don't mean coordiated outside our site. perhaps i didn't make that clear.
    >
    > what you're saying sounds like, say, putting some configuration in /rc/bin/cpurc.
    > the problem is that this information needs to be updated across all cpu servers
    > more often than everything is rebooted.
    >
    > perhaps a file on /srv/boot could be given to the fs which could be opened to check
    > group permission? too cute?
    >
    > - erik
    >


  9. Re: [9fans] the meaning of group

    > the problem is that this information needs to be updated across all cpu servers
    > more often than everything is rebooted.


    it seems to me that if this was a real requirement, and you wish group
    coordination across several machines, that you could add a kernel
    service, say #G, which would provide a file, say "groupquery", that
    some trusted process could read, in the style of factotum's needkey,
    to answer group requests for the kernel. inside the kernel, perhaps
    you'd provide call "ingroup(user, group)" to query whether a particular
    user was a member of a particular group - it would block until the
    request was answered, or return false if no process has opened the
    file.

    to speed things up, you could implement a simple leasing system which
    would allow ingroup() to cache answers for a while rather than going
    to user space each time.

    once you've got this primitive, you could link it to whatever you
    liked, for instance a fileserver instance, or a protocol mediated by
    factotum.

+ Reply to Thread