[9fans] the meaning of group

[9fans] the meaning of group

[erik quanstrom]

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

Re: [9fans] the meaning of group

[Charles Forsyth]

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

Re: [9fans] the meaning of group

[erik quanstrom]

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

Re: [9fans] the meaning of group

[Charles Forsyth]

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

Re: [9fans] the meaning of group

[erik quanstrom]

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

Re: [9fans] the meaning of group

[Charles Forsyth]

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

Re: [9fans] the meaning of group

[erik quanstrom]

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

Re: [9fans] the meaning of group

[Bruce Ellis]

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 <quanstro@quanstro.net> 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
>

Re: [9fans] the meaning of group

[roger peppe]

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