Erights - User contributions [en]

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:36:11 GMT

92.70.45.2: /* See also */

MinorFs is a small set of user space (Fuse) file-systems that provides process level and pseudo-persistent-process level decomposable and (capability style) discretionary access control. MinorFs uses sparse capabilities to designate file-system sub-trees. MinorFs is a particular good fit for use together with the [[E language]] for the reason that the E Language supports the concept of pseudo-persistent-processes with its persistent-storage bound persistent VATs. These VATs could be stored in MinorFS to protect the E application from attacks from below. Next to this MinorFs allows the (persistent) delegation of sub-trees of the (initially private) per pseudo-persistent-process file-system storage directory tree, and the (non persistent) delegation of sub-trees of the (initially private) per process file-system storage directory tree.
== See also ==
* [http://minorfs.polacanthus.net/wiki/MinorFs_and_E MinorFs and E]
* [[Walnut/Persistent Secure Distributed Computing]]
* [http://minorfs.polacanthus.net/wiki/MinorCapFS MinorCapFs]

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:35:53 GMT

92.70.45.2: /* See also */

MinorFs is a small set of user space (Fuse) file-systems that provides process level and pseudo-persistent-process level decomposable and (capability style) discretionary access control. MinorFs uses sparse capabilities to designate file-system sub-trees. MinorFs is a particular good fit for use together with the [[E language]] for the reason that the E Language supports the concept of pseudo-persistent-processes with its persistent-storage bound persistent VATs. These VATs could be stored in MinorFS to protect the E application from attacks from below. Next to this MinorFs allows the (persistent) delegation of sub-trees of the (initially private) per pseudo-persistent-process file-system storage directory tree, and the (non persistent) delegation of sub-trees of the (initially private) per process file-system storage directory tree.
== See also ==
* [http://minorfs.polacanthus.net/wiki/MinorFs_and_E MinorFs and E]
* [[Walnut/Persistent Secure Distributed Computing]]
* [[http://minorfs.polacanthus.net/wiki/MinorCapFS MinorCapFs]]

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:32:10 GMT

92.70.45.2: /* See also */

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:28:26 GMT

92.70.45.2:

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:26:37 GMT

92.70.45.2:

MinorFs is a small set of user space (Fuse) file-systems that provides process level and pseudo-persistent-process level decomposable and (capability style) discretionary access control. MinorFs uses sparse capabilities to designate file-system sub-trees. MinorFs is a particular good fit for use together with the [E Language] for the reason that the E Language supports the concept of pseudo-persistent-processes with its persistent-storage bound persistent VATs. These VATs could be stored in MinorFS to protect the E application from attacks from below. Next to this MinorFs allows the (persistent) delegation of sub-trees of the (initially private) per pseudo-persistent-process file-system storage directory tree, and the (non persistent) delegation of sub-trees of the (initially private) per process file-system storage directory tree.
== See also ==
* [http://minorfs.polacanthus.net/wiki/MinorFs_and_E MinorFs and E]

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:21:32 GMT

92.70.45.2:

MinorFs is a small set of user space (Fuse) file-systems that provides process level and pseudo-persistent-process level decomposable and (capability style) discretionary access control. MinorFs uses sparse capabilities to designate file-system sub-trees. MinorFs is a particular good fit for use together with the [E Language] for the reason that the E Language supports the concept of pseudo-persistent-processes with its persistent-storage bound persistent VATs. These VATs could be stored in MinorFS to protect the E application from attacks from below. Next to this MinorFs allows the (persistent) delegation of sub-trees of the (initially private) per pseudo-persistent-process file-system storage directory tree, and the (non persistent) delegation of sub-trees of the (initially private) per process file-system storage directory tree.

MinorFs

92.70.45.2 — Thu, 14 Apr 2011 10:21:09 GMT

92.70.45.2:

MinorFs is a small set of user space (Fuse) file-systems that provides process level and pseudo-persistent-process level decomposable and (capability style) discretionary access control. MinorFs uses sparse capabilities to designate filesystem sub-trees. MinorFs is a particular good fit for use together with the [E Language] for the reason that the E Language supports the concept of pseudo-persistent-processes with its persistent-storage bound persistent VATs. These VATs could be stored in MinorFS to protect the E application from attacks from below. Next to this MinorFs allows the (persistent) delegation of sub-trees of the (initialy private) per pseudo-persistent-process file-system storage directory tree, and the (non persistent) delegation of sub-trees of the (initialy private) per process file-system storage directory tree.

Capability

92.70.45.2 — Thu, 14 Apr 2011 10:04:03 GMT

92.70.45.2: /* Examples */

== Definition ==

A ''capability'' is a token that identifies an [[subject, object, operation and permission|object]] and provides its holder with the [[subject, object, operation and permission|permission]] to operate on the object it identifies. Capabilities must either be totally unforgeable or infeasible to forge by being ''sparse''.

== Examples ==
Some examples of unforgeable capabilities:
* Designations of objects in the [[E language]]. Those who hold these capabilities have the permission to invoke any method supported by the designated object.
* Designations of functions and procedures in [[Emily]]. Those who hold these capabilities have the permission to call designated functions or procedures.
* Capabilities held by a process in [[capability operating system]]s.
* POSIX file descriptors.
Some examples of sparse capabilities (sometimes called password capabilities):
* Designations of remote objects in E, such as <tt>captp://*orwqphzlugjwqj2wozz7tmg47ime466j@74.125.87.147:55189/oa6vn5whhapylswhzesdlqh5ppmjkcrq.</tt> Those who hold these capabilities have the permission to invoke any method supported by the designated object.
* Private URLs where having the URL is necessary and sufficient to use the resource. Common examples are:
** "Confirm your e-mail address" links for website account registrations and mailing list subscriptions.
** Shared private documents such as in Google Docs, Google Maps, [http://picasa.google.com Picasa] albums, [http://www.doodle.com Doodle] schedulers.
* Designation of file-system sub-trees in [[MinorFs]], such as <tt> /mnt/minorfs/cap/3d5d3efbf73bb711e7a47f82a44f471fcf77c70e/</tt>
{{XXX|What exactly do we mean by password capabilities here, such that a captp URL is not one?}}

== See also ==

{{XXX|improve this section}}

See [http://www.eros-os.org/essays/capintro.html What is a Capability, Anyway?] for a partisan explanation of what capabilities actually are.

See also [http://www.erights.org/elib/capability/overview.html Overview: Capability Computation]

{{stub}}

Capability

92.70.45.2 — Thu, 14 Apr 2011 09:57:06 GMT

92.70.45.2:

== Definition ==

A ''capability'' is a token that identifies an [[subject, object, operation and permission|object]] and provides its holder with the [[subject, object, operation and permission|permission]] to operate on the object it identifies. Capabilities must either be totally unforgeable or infeasible to forge by being ''sparse''.

== Examples ==
Some examples of unforgeable capabilities:
* Designations of objects in the [[E language]]. Those who hold these capabilities have the permission to invoke any method supported by the designated object.
* Designations of functions and procedures in [[Emily]]. Those who hold these capabilities have the permission to call designated functions or procedures.
* Capabilities held by a process in [[capability operating system]]s.
* POSIX file descriptors.
Some examples of sparse capabilities (sometimes called password capabilities):
* Designations of remote objects in E, such as <tt>captp://*orwqphzlugjwqj2wozz7tmg47ime466j@74.125.87.147:55189/oa6vn5whhapylswhzesdlqh5ppmjkcrq.</tt> Those who hold these capabilities have the permission to invoke any method supported by the designated object.
* Private URLs where having the URL is necessary and sufficient to use the resource. Common examples are:
** "Confirm your e-mail address" links for website account registrations and mailing list subscriptions.
** Shared private documents such as in Google Docs, Google Maps, [http://picasa.google.com Picasa] albums, [http://www.doodle.com Doodle] schedulers.
* Designation of file-system sub-trees in MinorFs, such as <tt> /mnt/minorfs/cap/3d5d3efbf73bb711e7a47f82a44f471fcf77c70e/</tt>
{{XXX|What exactly do we mean by password capabilities here, such that a captp URL is not one?}}

== See also ==

{{XXX|improve this section}}

See [http://www.eros-os.org/essays/capintro.html What is a Capability, Anyway?] for a partisan explanation of what capabilities actually are.

See also [http://www.erights.org/elib/capability/overview.html Overview: Capability Computation]

{{stub}}