[cap-talk] POLA? Unix FDs as capabilities? Plash future + YURLs?

[Jed at Webstart]

At 09:19 AM 11/19/2005, Tyler Close wrote:
>On 11/17/05, Jed at Webstart <donnelley1 at webstart.com> wrote:
> > At 04:19 PM 11/17/2005, Toby Murray wrote:
> > >Jed at Webstart wrote:
> > >>On the other hand, perhaps Tyler's YURLs and the Web can serve for
> > >>the permanent management of resource access?  Then if Plash could
> > >>communicate "capabilities" to processes as open file descriptors
> > >>that represent pipes to a local server that accesses the
> > >>corresponding resources through YURLs ...  Well, that is getting
> > >>ahead of the game, but I could imagine it.  Quite a hack and
> > >>probably unworkable, but close to satisfying the basic needs.
> > >
> > >This is quite interesting. I'm imagining (from your description)
> > >YURLs as a sort of "universal" capability representation that is
> > >machine independent (like E's sturdyref's I suppose), where on the
> > >Unix implementation we use file descriptors to represent them
> > >locally. YURLs are "resolved" to local file descriptors, like E
> > >sturdyrefs are "resolved" to object references. (please excuse me if
> > >I've got the terminology wrong here, I'm no E hacker).
>
>As Jed wrote, I once implemented something very similar to this.
>Instead of binding a YURL to a file descriptor, I bound a YURL to an
>operation on a file descriptor. A single file therefore had a set of
>YURLs bound to it, one for each exported operation. For example, there
>was a YURL to fetch the current file contents, another to overwrite
>the file and another to delete the file.

If I'm understanding this properly it sounds like you essentially implemented
permissions (e.g. access bits like rw) with separate YURLs.  Does that
mean I would have to have several YURLs if I essentially 'owned' the file,
e.g. one for each of the operations I was able to do on the file?  I'm
sure you're familiar with the typical capability approach where permissions
come along with the authority encoded in the capability.  E.g. in some
of the capabilities as data mechanisms (e.g. Amoeba and NLTSS)
schemes were developed to allow one capability to suffice in that
situation.  To generate a reduced authority capability for the same
resource one would perform an operation of the more powerful
capability to generate one of less power.  Sorry for the tome - just
curious if you've touched on this area.

>There was a similar schema
>for directory operations. The resulting application was quite useful
>for remote file management through a web browser; however, people
>mostly used it as a crude form of wiki. This lead me to build a less
>crude wiki that you can find at <https://yurl.net/>.

In what sense does the above constitute a "wiki".  If a wiki, how do
I modify content?

>Reviving the file management application might be fun and useful.
>
>I never built the reverse mapping of turning operations on file
>descriptors into HTTP requests on YURLs, though I lusted for it. Such
>a mapping would enable use of vim for remote file management, which
>may be preferable to the web browser for many tasks.

That would indeed be an interesting facility.  Worthy of a paper I think if
you were interested in such things.

I feel that to effectively be able to demo/sell YURLs I need what amounts
to a file server and directory server behind YURL 'capabilities'.  You had
that at one time in a demo and I still feel I'm missing it for selling YURLs.
Maybe I should just try to block out some time over the holidays and
implement such a thing ...

--Jed http://www.webstart.com/jed/