AppFS, a FUSE filesystem via HTTP for running software without installing it | Hacker News Reader

AppFS, a FUSE filesystem via HTTP for running software without installing it

appfs.rkeene.org

38 pointsrkeene215 comments

This is built into OS X:

hdiutil attach https://adiumx.cachefly.net/Adium_1.5.10.1.dmg -shadow Adium.shadowfile

The -shadow option allows the image to be mounted read-write, with writes being redirected into the shadow file.

I'm not an Apple guy so let me ask a naive question: is this even close to a functional equivalent? Quick research makes this look like just mounting a remote filesystem.

That's very different than being a package format, with dependency resolution, caching equivalent files, etc.

Yes it is mounting a remote filesystem, it does not have all the same features. I was replying to the title "a FUSE filesystem via HTTP for running software without installing it," which the above command permits; the linked page (at least without exploring deeper into the site) doesn't describe dependency resolution. Caching will performed by the kernel, but I don't know how it operates in a multi-user environment.

Dependency resolution is implicit to the design -- the entire global namespace is available on every system so any dependencies are resolved as they are requested.

That is, if you have an executable such as "ls" that relies upon the dynamic linker provided by "glibc", then the glibc requested will be fetched automatically because you attempted to open the dynamic linker.

Additionally, the design is superior to the single-user nature of a remote disk image in that each user's writes are redirected to their own home directory (by default, you can change this in a config file).

Even further, it allows for setuid files to be handled safely which is sometimes needed (e.g., "sudo" or "chrome-sandbox").

Caching is handled by the kernel for the VFS cache but also by a more persistent disk cache so that you can use applications offline as long as you have cached them (by running them, usually) ahead of time.

We also have SSHFS. Like on any system? (Probably not windows, no idea, but that sucks anyway for any producivity)

AppFS is built on FUSE just like SSHFS, it just uses a different transport protocol, doesn't support pushing writes back the origin server, does heavy caching, safely supports multiple users (including writes), can safely connect to untrusted servers (uses end-to-end PKI, so verification works even if the original URLs are not the same for example if mirroring is used), and handles setuid-root files in a safe way.

While I like the foundation of this idea, I'd love to see it taken to the next logical conclusion: Drop HTTP for a better suited protocol (like 9P), and correctly handle the interaction of union'd (namespaced) filesystems.

The backend actually doesn't care about the protocol used and indeed any protocol could be transparently substituted in using the config file... However there is nothing that makes 9P better suited in this particular case since the resources requested are completely static URLs with the exception of the "index" resource which lists the SHA1 of the list-of-packages as well as the digital signature of the "index" file itself.

from a security standpoint, this is terrifying. one infected application over FUSE could potentially compromise thousands of users.

It's the same as any other package repository being compromised. There's currently no key revokation, like most package systems but being based on X.509 it certainly supports it.

Additionally the only part of AppFS that runs as a privileged user is the daemon itself, unlike most package systems where there is an install step that can run arbitrary scripts as a privileged user.

Sadly, X.509 has been rendered useless due to certificate authority compromises, and the need to trust keys from those CA's. if something else was chosen, it might be far less terrifying.

What ? The CA AppFS trusts has never been compromised and you are free to replace it. It sounds like you think SSL/TLS is being used or something or that many certificate authorities are trusted.

is this another implementation of zero-install, by the guys who did the rox filer (port of riscos file manager to *nix) ?

Viewing the link at it states:

> It is similar to the the original 0install implementation, LazyFS. It supports many features required for large scale deployments. It has the following fancy features:

It is very similar with some small (but significant) differences: 1. It doesn't require a huge manifest per site, instead the manifests are broken down into: list-of-packages-per-site and list-of-files-per-package 2. There are no special directories in the same namespace that regular files can live in 3. It is deduplicated (every file is referenced by its SHA1) making the need for making packages share files that they have in common unnecessary. 4. It lives in a more sane place in the UNIX filesystem (/opt) 5. It doesn't use special characters to denote special meaning (this is why I stopped using LazyFS) 6. It uses FUSE instead of its own kernel module

Reply on news.ycombinator.com