[tahoe-lafs-trac-stream] [tahoe-lafs] #1353: make the FUSE interface be a supported, first-class feature

[tahoe-lafs]

#1353: make the FUSE interface be a supported, first-class feature
-------------------------------+--------------------------------------------
     Reporter:  zooko          |       Owner:  somebody 
         Type:  enhancement    |      Status:  new      
     Priority:  major          |   Milestone:  undecided
    Component:  documentation  |     Version:  1.8.2    
   Resolution:                 |    Keywords:  fuse docs
Launchpad Bug:                 |  
-------------------------------+--------------------------------------------

Comment (by davidsarah):

 Replying to [comment:1 gdt]:
 > The SFTP interface is cool, and I think should stay, but saying our fuse
 answer is to use it seems kludgy, and extended attributes and caching will
 be harder.

 (I don't agree about SFTP+sshfs being "kludgy", but I'll answer that
 separately. Extended attributes are indeed harder, but note that sshfs
 already does some caching.)

 > We need a way for someone to use the CLI to do
 > {{{
 > tahoe mount [ALIAS:][PATH] [system-path]
 > }}}
 > or perhaps just alias:, and require an alias for a sub-path.  Note that
 there is no sftp login, no ssh credentials, just reading the cap out of
 the .tahoe directory.

 We can do that with sshfs. Allow logging in with username 'uri', and
 password the root URI to be used.

 Then make the above {{{tahoe mount}}} command resolve {{{[ALIAS:][PATH]}}}
 to an URI, and execute:
 {{{
 sshfs uri at GATEWAY -p SFTP_PORT -o password_stdin
 }}}
 passing the URI on stdin.

 > Perhaps system-path defaults to ~/TAHOE/ALIAS.

 I don't think there should be any default for the mount point, but that's
 a detail.

 > the FUSE module should then allow requests only from the same uid that
 did the mount, and maybe root, and have an option to allow anyone who
 could access the original directory to do things - I'm not sure but one
 has to translate system access control to tahoe access control.

 Why? The user who invokes {{{tahoe mount}}} can put the mount point
 somewhere that only they can access, if that's what they want. (It might
 not be what they want, and I don't see any reason to restrict them from
 putting the mount point anywhere that the OS allows them to.)

 > This will then point out that having files be chmod +x would be
 sensible, which leads to tahoe storing attributes.

 That seems like a completely separate issue.

 > The really hard part is dealing with immutable files and the illusion of
 writing to them.  Maybe they're just read-only and one has to write/rename
 which is what should happen anyway.

 The SFTP interface already deals with this; writing to a path that
 resolves to an immutable file will replace the entry in the parent
 directory (and is possible only when that directory is writeable).

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1353#comment:3>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage