public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Rob Meijer" <capibara@xs4all.nl>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor
Date: Fri, 2 Sep 2011 22:32:38 +0200	[thread overview]
Message-ID: <d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl> (raw)
In-Reply-To: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>

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).

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

On Fri, August 26, 2011 09:48, Rob Meijer wrote:
> A few years ago I wrote a least authority based set of filesystems named
> MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
> pseudo persistent processes' their own private but decomposable and
> delegatable piece of filesystem storage:
>
> http://www.linuxjournal.com/magazine/minorfs
> http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
>
> Currently there is only one perfect fit for MinorFs and that's the stack
> AppArmor/MinorFs/E-language-persistent-application. There are some close
> fits like running ssh without a passphrase (
> http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )
> but these require lots of manual fiddling by the user to get working. The
> ssh trick would probably work with bitcoin, but as you can see from the
> link above, it would be rather cumbersome.
>
> I am trying to get specs together for rewriting MinorFs (in Python) in a
> way that would make it easy and natural for application developers that
> want their application to be able to protect user data (like bitcoin
> wallets) from mallware running under the same uid as that user.
>
> Currently minorfs granularity is hard fixed to that of the 'pseudo
> persistent process', and that granularity is determined as described in
> the following link:
>
> http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
>
> When using pseudo persistent processes, you basically end up with
> file-system storage that follows almost all of the modeling principles of
> the object capability model. This is great when designing a least
> authority program from scratch and writing it in the (object capability)
> e-language using its persistence facilities.
>
> Given however that I don't expect bitcoin, openssh, chrome, firefox, or
> any other application that would benefit from what MinorFs provides to be
> rewritten in E, it seems like the next version of MinorFs should give up
> on the purity of its least authority model, and take an approach that
> better suits common development languages and practices.
>
> With bitcoin being a project that could benefit most from what MinorFs has
> to offer, I would like to ask bitcoin developers to think about what
> attributes from the current granularity level (pseudo persistent process)
> should be kept, what attributes should be dropped, and what properties
> should be added to arrive at an 'id' that is the best fit for granularity
> of persistent private storage for bitcoin.
>
> I really want to accommodate bitcoin developer needs in this, so all input
> that helps me help you guys to get the next MinorFs version to accommodate
> your needs to a level that code to use MinorFs where available can be
> added to bitcoin, would be extremely welcome.
>
> Let me know what you think,
>
> Rob
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>





  reply	other threads:[~2011-09-02 20:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-26  7:48 [Bitcoin-development] BitCoin and MinorFs/AppArmor Rob Meijer
2011-09-02 20:32 ` Rob Meijer [this message]
2011-09-02 22:05   ` Nils Schneider
2011-09-05 11:55     ` Rob Meijer
2011-10-08 22:51       ` Rob Meijer
2011-09-03  7:04   ` John Smith
2011-09-05 12:13     ` Rob Meijer
2013-01-10 17:41 ` Rob Meijer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl \
    --to=capibara@xs4all.nl \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=rmeijer@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox