"Trusted Hashes"

[whyrusleeping]

Ive been thinking about being able to execute binaries directly out of ipfs, this would require us to set them as +x (or equivalent). But we dont want to set everything in ipfs as executable. It would be nice to have a config setting to say that QmAcoolBinary is an executable we trust. Then the fuse filesystem can see that and when presenting it to the user through the fuse interface, mark it as executable.

[jbenet]

Agreed. Right now it's all +x which is pretty sketchy. wonder if we can get away making this the same kind of trust for the webui and other js apps with access to the api, or it needs to be its own things.

tentatively:

ipfs trust <path>
ipfs trust add <path>
ipfs trust rm <path>

# could even have flags, like +x
ipfs trust +x <path>
ipfs trust -x <path>

# chould even call it chmod, with our own set of flags.
ipfs chmod +x <path>
ipfs chmod -x <path>

• could use something like afs' rlidwka
• what's the state of the art in permissions?

[whyrusleeping]

what's the state of the art in permissions?

Now theres the question we should be asking

[jbenet]

This needs to be speced out first

[wking]

On Mon, Mar 02, 2015 at 06:41:39PM -0800, Jeromy Johnson wrote:

what's the state of the art in permissions?

Now theres the question we should be asking

I disagree ;). IPFS is breaking ground in distributing filesystems.
We don't want to be pushing the permissions envelope at the same
time. I'd recommend we support at least POSIX permissions
(i.e. chmod's mode 1), and put off worrying about fancier
permissions information (user and group names, access control lists,
…) until later. This seems reasonable with the FUSE approach, since
fuse.h (from FUSE v2.9.3) has:

struct fuse_operations {
…

/** Change the permission bits of a file */
int (*chmod) (const char *, mode_t);

…

/** File open operation
 *
 * …
 *
 * Unless the 'default_permissions' mount option is given,
 * open should check if the operation is permitted for the
 * given flags. Optionally open may also return an arbitrary
 * filehandle in the fuse_file_info structure, which will be
 * passed to all file operations.
 *
 * Changed in version 2.2
 */
int (*open) (const char *, struct fuse_file_info *);

…

/**
 * Check file access permissions
 *
 * This will be called for the access() system call.  If the
 * 'default_permissions' mount option is given, this method is not
 * called.
 *
 * This method is not called under Linux kernel versions 2.4.x
 *
 * Introduced in version 2.5
 */
int (*access) (const char *, int);

and bazil.org/fuse has the following struct for file and directory
metadata 2:

type Attr struct {
Inode uint64 // inode number
Size uint64 // size in bytes
Blocks uint64 // size in blocks
Atime time.Time // time of last access
Mtime time.Time // time of last modification
Ctime time.Time // time of last inode change
Crtime time.Time // time of creation (OS X only)
Mode os.FileMode // file mode
Nlink uint32 // number of links
Uid uint32 // owner uid
Gid uint32 // group gid
Rdev uint32 // device numbers
Flags uint32 // chflags(2) flags (OS X only)
}

I haven't looked at the Darwin code yet, but we'd want to slot in the
object-based modes here 3, replacing the current, hardcoded values.

[wilkie]

Hey, I think this discussion is close to what I'm dealing with, so I'll ask here since my ideas revolve around executables and distributed execution... primarily for use in software archival and scientific digital reproducibility.

The permissions I see from the mounted filesystem are always +r and don't have +x so they can't be executed. Is that right? It seems here that they were +x at some point. I'd like to have that capability and secure access to the mount in a higher level. Is that possible?