From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QzkHb-0001h3-PJ for bitcoin-development@lists.sourceforge.net; Sat, 03 Sep 2011 07:04:51 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.175 as permitted sender) client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com; helo=mail-yx0-f175.google.com; Received: from mail-yx0-f175.google.com ([209.85.213.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QzkHa-0006xv-OH for bitcoin-development@lists.sourceforge.net; Sat, 03 Sep 2011 07:04:51 +0000 Received: by yxl11 with SMTP id 11so1875814yxl.34 for ; Sat, 03 Sep 2011 00:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.148.6 with SMTP id a6mr1728502ybo.178.1315033484987; Sat, 03 Sep 2011 00:04:44 -0700 (PDT) Received: by 10.151.100.12 with HTTP; Sat, 3 Sep 2011 00:04:44 -0700 (PDT) In-Reply-To: References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl> Date: Sat, 3 Sep 2011 07:04:44 +0000 Message-ID: From: John Smith To: rmeijer@xs4all.nl Content-Type: multipart/alternative; boundary=00151750ed5cbd8d4904ac041740 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service X-Headers-End: 1QzkHa-0006xv-OH 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 07:04:51 -0000 --00151750ed5cbd8d4904ac041740 Content-Type: text/plain; charset=ISO-8859-1 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? 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? JS --00151750ed5cbd8d4904ac041740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <= span dir=3D"ltr"><capibara@xs4all.nl> wrote:

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<= br> with Bitcoin more likely, I'm open to all sugestions:

http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2<= br>

You have to rewrite the entire thing from scratch?=

This is probably blasphemy but: how can it be compared to the android m= odel, with a UID per application/user, and thus layering the security on to= p of current UNIX/ACL permissions?=A0 Is another FS really needed?

JS

--00151750ed5cbd8d4904ac041740--