From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: Daniel Lyons To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <4250f2c330ba83eb6bfc7380766c17c3@quanstro.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 6 Aug 2009 13:33:40 -0600 References: <4250f2c330ba83eb6bfc7380766c17c3@quanstro.net> Subject: Re: [9fans] linux reinvents factotum, secstore ... Topicbox-Message-UUID: 3a4d34de-ead5-11e9-9d60-3106f5b1d025 On Aug 6, 2009, at 12:13 PM, erik quanstrom wrote: > poorly. massive, overengineered, and yet lacking: > > http://lwn.net/Articles/344117 Ugh. A brief apology on their behalf, though. I have been trying to =20 understand the workings of factotum, secstore, auth/keyfs and whatnot =20= for a while and I'm just now starting to get the feeling that I might =20= have a grasp on how all these things work together in concert to do =20 their jobs. There is a propensity to develop software starting from the interface =20= working backwards to the functionality. When enough people reduplicate =20= a functionality, they decide to move the functionality out. This is =20 what you're going to get when you evolve software rather than =20 architect it. One of the things I have been impressed with in Plan 9 =20 is that generally each layer of abstraction is comprehensive. On Linux =20= there is a tendency to have to keep adding more layers upon the =20 layers. This security framework, for example, relies on D-Bus for =20 communication. The appearance of hal, the "hardware abstraction layer" =20= a few years ago struck me too. Isn't that what the OS is supposed to =20 provide? Maybe it would have been feasible to add whatever it adds if =20= more of the drivers were in user space rather than kernel space. It's easy for me to object to what they're coming up with but it would =20= be hard for me to describe in detail how exactly factotum + all the =20 other stuff encompass it, and I don't think that the paper we have on =20= factotum or the section in nemo's book are sufficient either. As a =20 devil's advocate, in my Mac keychain I have 13 keys related to file =20 shares and 22 WEP keys. I have my SSH key on 24 machines. Then I have =20= 270 web form passwords or internet passwords in my keychain. Does =20 factotum handle web passwords? I'm presuming not but I don't really =20 know because I generally surf with Safari or Firefox outside Plan 9. =20 I'm not complaining about the browser situation, I'm just saying, it =20 seems to me that the average user probably has more website usernames =20= and passwords than everything else combined. That's certainly the case =20= with me. Could factotum be adapt to integrate with a browser and store =20= web form secrets? If so that would be a compelling objection, since it =20= looks like Firefox isn't going to start using their security framework =20= anytime soon. And who can blame them? It already has a ton of =20 dependencies and porting issues and this can only exacerbate it. It might raise our profile a bit if someone who has a comprehensive =20 understanding of the security framework in Plan 9 would write a =20 rebuttal to this announcement, something along the lines of "Plan 9: =20 An Integrated Approach to Grid Computing" by Andrey Mirtchovski, Rob =20 Simmonds and Ron Minnich. That paper works largely as a refutation of =20= the complexity of the Globus Toolkit. It would also be helpful to =20 people like myself who are recent adopters of Plan 9 and don't have a =20= comprehensive understanding of the security architecture=97perhaps =20 because we've been poisoned by systems like Mac OS X Keychain and SSH. =97 Daniel Lyons