Re: [9fans] group ownership for shared devices

Re: [9fans] group ownership for shared devices

[José Brandão]

Sorry for my ignorance, but is this not what importfs is for ?

Re: [9fans] group ownership for shared devices

[José Brandão]

I stand corrected.

Re: [9fans] group ownership for shared devices

[erik quanstrom]

On Tue Nov 10 08:25:22 EST 2009, ze.brandao@gmail.com wrote:
> Sorry for my ignorance, but is this not what importfs is for ?

what is importfs?

if you mean exportfs, it's not going to do what lyndon wants
you can import devices as a normal user

	; import -E ssl minooka.coraid.com '#æ' /n/mæ

but that doesn't change the system's idea of who you are

	; cd /n/mæ/aoe && ls -l
	--rw-r--r-- M 71124 bootes bootes 0 Oct 28 12:26 ctl
	--r--r--r-- M 71124 bootes bootes 0 Oct 28 12:26 log
	; echo bind '#l1/ether1' > ctl
	ctl: rc: can't open: 'ctl' './aoe/ctl' permission denied

you can import as another user, say bootes.  but in order to
do that, every member of the group has to have bootes'
password.  but if that were the case, lyndon's users could just
cpu in as bootes.

- erik

[9fans] group ownership for shared devices

[Lyndon Nerenberg]

I have a CPU server running as 'glenda' that has a DVD drive. I want to
make that DVD drive available to various terminals on the network. But I
don't want to put the terminal users into glenda's group. The obvious
solution seemed to be to set up a 'commondevs' group, add glenda and the
allowed device users to it, then have the CPU server 'chgrp commondevs
/dev/...' but no joy there. There's got to be something stunningly simple
here that I'm missing ...

--lyndon

Re: [9fans] group ownership for shared devices

[Russ Cox]

On Mon, Nov 9, 2009 at 9:44 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> I have a CPU server running as 'glenda' that has a DVD drive. I want to make
> that DVD drive available to various terminals on the network. But I don't
> want to put the terminal users into glenda's group. The obvious
> solution seemed to be to set up a 'commondevs' group, add glenda and the
> allowed device users to it, then have the CPU server 'chgrp commondevs
> /dev/...' but no joy there. There's got to be something stunningly simple
> here that I'm missing ...

This solution didn't work because groups are specific to the
file server implementing them.  Your CPU server doesn't know
about the groups on your file servers and doesn't itself
implement any groups.

You could hack up a copy of srvfs that looks at the user
name being presented over the 9P connection and makes
the decision that way, or you could write a custom file server
with its own group list, like consolefs has.

Russ

Re: [9fans] group ownership for shared devices

[Lyndon Nerenberg]

> or you could write a custom file server
> with its own group list, like consolefs has.

This seems to make the most sense. And it makes it simple to implement
(configurable) exclusive open semantics for devices that need it.

--lyndon

Re: [9fans] group ownership for shared devices

[Lyndon Nerenberg]

> This solution didn't work because groups are specific to the
> file server implementing them.  Your CPU server doesn't know
> about the groups on your file servers and doesn't itself
> implement any groups.

I'm suffering more 2ed->4ed migration brain damage. After reading through
some of the assorted fileserver code I see what you mean. The [m][ug]id
fields in stat seem somewhat arbitrary these days.

It might be nice if fileservers that just make up [ug]ids to satisfy stat
or otherwise ignore permissions returned 'none' or something equivalent in
those fields, just as a hint.

--lyndon