From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <547A2280.4020407@gr13.net> Date: Sat, 29 Nov 2014 20:46:08 +0100 From: "Enrico Weigelt, metux IT consult" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: 9fans@9fans.net References: <546981BE.90704@gr13.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Factotum vs SASL Topicbox-Message-UUID: 2f03546a-ead9-11e9-9d60-3106f5b1d025 On 18.11.2014 09:22, Skip Tavakkolian wrote: thanks folks ... seems I need to think through all of this more deeply. If I'm not completely mistaken, factotum can also handle various authentication protocols, and may be the only one who really knows the actual secrets. One scenario I'm thinking about is replacing the password-stores in certain browsers by an factotum (maybe it could also be useful for cert handling ?) A really cool feature, IMHO, would be able to connect my local factotum to remote ones easily, so I'll get a similar feature like eg. lastpass is doing for the web. For example, somebody like to give me access to some remote application, but for some reason can't add my pubkey there (eg. it doesn't even support such things), but doesn't want to give me cleartext passwords, he could set things up in his (publically accessible) factotum instance, which then handles all the auth stuff for that application. By the way, that leads me to another topic, which is annoying me for quite some time: policykit. For those, who have been spared of it: It's an invention of the freedesktop folks (or should I call them "Lennartists" ? ;-o), some kind of proxy, which routes certain dbus calls (based on certain policies) between several users (and root). This way, eg. unprivileged users can still be given access to system level stuff, like network-manager. And that's exactly the point which regularily hit me (eg. some day my primary account suddenly wasn't able to choose wireless networks anymore, and even the old fashioned way via unix groups didn't help either). So, I'm thinking about a cleaner solution - obviously not dbus, but 9P. If i understand it correctly, in 9P, the server is in charge of handling all the access control. So, I can't just write some simple 9P server, mount it anywhere and magically expect it working just by file ownerships (by the way: do they have any practical meaning at all ?). Obviously, the server needs to know who the calling user is and whether he shall be allowed to access certain items - more precisely whether he is in the right role right now. And these things could be depending on other parameters (defined by other parties), eg. when reboot shall only be allowed when logged-in locally, and no other blocking parts (eg. important tasks) currently running. Pretty clear, that these things shouldn't be implemented in each single service separately, and not every service that might have an influence here shall have to talk to everybody else. So, how would a Plan9 solution for these usecases look like ? In fact, I intend to rewrite network-manager to some 9p-based solution, so I'd like to discuss this carefully before starting to lennert up something stupid. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287