Transport-agnostic synchronous network filesystem with support for reverse connect
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
Go to file
Jan Engelhardt 395823fd8d
doc: switch readme to rST
3 months ago
doc doc: switch readme to rST 3 months ago
etc build: move to non-recursive make 9 months ago
src fifo: cure crash when run / add mising HXOPT_TABLEEND 3 months ago
.gitignore build: move to non-recursive make 9 months ago
INSTALL build: remove --with-slibdir 10 years ago
LICENSE.GPL2 Initial import 15 years ago
LICENSE.GPL3 Add missing GPL3 license text 15 years ago
Makefile.am build: drop support for Linux < 2.6.16 9 months ago
README.rst doc: switch readme to rST 3 months ago
autogen.sh Initial import 15 years ago
configure.ac build: drop support for FUSE < 2.7.0 9 months ago
gen_xl.pl Add open flags translation layer 15 years ago

README.rst

CC Network Filesystem (ccgfs)

ccgfs is a transport-agnostic filesystem; transport is arranged by helper programs, such as ssh. Common transport modes are "pull" and "push", the latter of which makes it possible to export a filesystem located in a LAN to a DMZ host without defeating the DMZ security model which prohibits connections to the LAN, which the pull model would require.

Most, if not all, networked filesystems use a pull model, where a client sends a mount request to a server. (Because the push model reverses roles, the terms "mount endpoint" and "storage endpoint" will be used to avoid confusion.) So in the pull model, a mount endpoint opens a connection to the storage endpoint. This however is a problem when you want a host in a DMZ network to access data that is located in the inner LAN, because you would need to allow connections from the DMZ to the LAN on the firewall, which is contrary to the principle of a DMZ.

One could move the storage unit into the DMZ itself, but that may create interoperability problems with LAN clients, e.g. with SMB clients using NBT broadcast. Or you do not want to move it to the DMZ, because it is your only workhorse in the LAN. To solve this issue without moving the storage unit into the DMZ itself, a filesystem that can be pushed is needed. (Since connections from LAN to DMZ are always allowed.) Classical networked filesystems do not seem to be able to do that.

Actually, this is only a transport issue. Classical (pull-based) networked filesystems could be made transport-agnostic, but it would take more time to develop that. The requirements were:

  • must support ACLs/xattrs
  • should support quotas if possible
  • connection must be encryptable if desired
  • implementation should be simple
  • and perhaps modularized
  • (it should not take too long to implement push-based operation for it)