From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 29 Nov 2014 13:23:44 -0800 To: 9fans@9fans.net Message-ID: <7fed26ea40724d100df8e86bb79b0a32@lilly.quanstro.net> In-Reply-To: <547A388C.2030006@gr13.net> References: <546981BE.90704@gr13.net> <547A2280.4020407@gr13.net> <547A388C.2030006@gr13.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Factotum vs SASL Topicbox-Message-UUID: 2f27683c-ead9-11e9-9d60-3106f5b1d025 > In my scenario, I'm (more precisely: the account I'm using) not the > hostowner, just a plain user - in Unix terms: non-root). But that > account has the special privileges of controlling the network > connections. Other accounts may only choose from a predefined list > of connections. if you've logged into a plan 9 terminal, then you *are* the hostowner. this is a non-problem. "in Unix terms" doesn't work here. root != hostowner. they are very different concepts. > The network itself is controlled by some separate service (eg. network > manager - which eg. comes quite handy for travelers, etc). Now we need > to decide which accounts may control it or just see some status. again, this is not how a plan 9 box would work. when you log into the machine, you own all the h/w. you can do what you want. > A traditional unix/linux approach (for local-only) would be handling > that via groups and file permissions for the command sockets. The > decision then would be done on login time, as the uids and gids are > set here. again, ... > For a plan9-alike approach, I could imagine something where the > factotums handle everything, so the service finally just sees an > pseudo-user or role, and the host-factotum does the translation, > based on some table (similar to /etc/group). For the network-manager > example, there could be roles like "network-admin", "network-ctrl", > "network-stat". Maybe we could even extend the factotum protocol, > so it directly supports roles. no factotum need apply. :-) - erik