Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R0Y40-0001vz-NA for bitcoin-development@lists.sourceforge.net; Mon, 05 Sep 2011 12:14:08 +0000 X-ACL-Warn: Received: from smtp-vbr13.xs4all.nl ([194.109.24.33]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1R0Y3w-0008Mb-M9 for bitcoin-development@lists.sourceforge.net; Mon, 05 Sep 2011 12:14:08 +0000 Received: from webmail.xs4all.nl (dovemail18.xs4all.nl [194.109.26.20]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id p85CDr9j010797; Mon, 5 Sep 2011 14:13:53 +0200 (CEST) (envelope-from capibara@xs4all.nl) Received: from 92.70.45.2 (SquirrelMail authenticated user rmeijer) by webmail.xs4all.nl with HTTP; Mon, 5 Sep 2011 14:13:58 +0200 Message-ID: <93ffca16f2e9178f302e8b1c0dc52afe.squirrel@webmail.xs4all.nl> In-Reply-To: References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl> Date: Mon, 5 Sep 2011 14:13:58 +0200 From: "Rob Meijer" To: "John Smith" User-Agent: SquirrelMail/1.4.18 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [194.109.24.33 listed in list.dnswl.org] -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1R0Y3w-0008Mb-M9 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rmeijer@xs4all.nl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 12:14:08 -0000 On Sat, September 3, 2011 09:04, John Smith wrote: > On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer wrote: > >> Given that there was not a single response to my post, I gather there is >> no to little interest in an updated MinorFs that could be used by >> bitcoin >> on systems that support AppArmor (Ubuntu and OpenSuse). >> > > Oh yes there is interest. I meant to reply but haven't been able to put > much > energy in bitcoin development lately. > > More strict privilege seperation between applications on a least-authority > basis is something that Ubuntu is certainly going to need if they're > serious > with the app store thing (and want to keep up with Android and Macosx...). > > This has been needed for a long time, and this would be useful for any > private data managed by applications running as the same user (ssh, > browsers, pgp, ...) > > Wallet encryption is useful and necessary but no substitute for OS-level > protection. > > >> Nevertheless I've put down the initial set of specs for a rewrite of >> MinorFs for if anyone would like to comment on them to make a future >> match >> with Bitcoin more likely, I'm open to all sugestions: >> >> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2 >> > > You have to rewrite the entire thing from scratch? I think its best. The old version I wrote in Perl using some rather rarely used perl modules from cpan that don't have packages in either opensuse nor ubuntu. I've moved most of my other new development projects to Python or C++ for a long time, so Python has become much more natural for me to work in, while migrating all perl module usage to a packaging compatible set would also be a pretty large task. From this I concluded that it would probably be best to take lessons learned from the existing MinorFs and do a rewrite in Python, making sure all python modules used are available in both OpenSuse and ubuntu. > This is probably blasphemy but: how can it be compared to the android > model, > with a UID per application/user, and thus layering the security on top of > current UNIX/ACL permissions? Is another FS really needed? MinorFs IS basically a set of user space file-systems on top of current UNIX/ACL permissions. Without further changes with application granularity and without delegation of sub-trees, the two are basically equivalent. The plans I currently have will allow a migration path from such a model to one with a finer granularity level where sub systems delegate sub trees to eachother in a pass by reference way. > JS >