Rob Meijer [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-05 🗒️ Summary of this message: John Smith ...
📅 Original date posted:2011-09-05
🗒️ Summary of this message: John Smith expresses interest in an updated MinorFs for Bitcoin on systems that support AppArmor, and suggests a rewrite in Python for compatibility.
📝 Original message:On Sat, September 3, 2011 09:04, John Smith wrote:
> On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara at 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
>
🗒️ Summary of this message: John Smith expresses interest in an updated MinorFs for Bitcoin on systems that support AppArmor, and suggests a rewrite in Python for compatibility.
📝 Original message:On Sat, September 3, 2011 09:04, John Smith wrote:
> On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara at 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
>