From: "Rob Meijer" <capibara@xs4all•nl>
To: "John Smith" <witchspace81@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor
Date: Mon, 5 Sep 2011 14:13:58 +0200 [thread overview]
Message-ID: <93ffca16f2e9178f302e8b1c0dc52afe.squirrel@webmail.xs4all.nl> (raw)
In-Reply-To: <CAJNQ0stL3yP9mJtPMEjWZeHtKT-3kZ+Psbpfs1XtVnEnd6x2gQ@mail.gmail.com>
On Sat, September 3, 2011 09:04, John Smith wrote:
> On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara@xs4all•nl> 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
>
next prev parent reply other threads:[~2011-09-05 12:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 7:48 Rob Meijer
2011-09-02 20:32 ` Rob Meijer
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 [this message]
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=93ffca16f2e9178f302e8b1c0dc52afe.squirrel@webmail.xs4all.nl \
--to=capibara@xs4all$(echo .)nl \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=rmeijer@xs4all$(echo .)nl \
--cc=witchspace81@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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