Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[9fans] group ownership for shared devices

1 view
Skip to first unread message

Lyndon Nerenberg

unread,
Nov 10, 2009, 12:48:06 AM11/10/09
to
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

Russ Cox

unread,
Nov 10, 2009, 1:03:31 AM11/10/09
to

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

Lyndon Nerenberg

unread,
Nov 10, 2009, 1:27:52 AM11/10/09
to
> 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

Lyndon Nerenberg

unread,
Nov 10, 2009, 2:23:35 AM11/10/09
to
> 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

José Brandão

unread,
Nov 10, 2009, 8:28:47 AM11/10/09
to
Sorry for my ignorance, but is this not what importfs is for ?

erik quanstrom

unread,
Nov 10, 2009, 9:04:48 AM11/10/09
to
On Tue Nov 10 08:25:22 EST 2009, ze.br...@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

José Brandão

unread,
Nov 10, 2009, 10:31:35 AM11/10/09
to
I stand corrected.

0 new messages