Domain: fs.net
Stories and comments across the archive that link to fs.net.
Comments · 25
-
Simple Asynchronous File Transfer
I use saft, the simple asynchronous file transfer system. I don't know if it has a windows implementation, but it's great for sharing files with someone else directly.
Far far better is SFS, the self-certifying filesystem. It's more trouble to setup (unless you use Debian) but it allows you to create a secure NFS mount that can safely be mounted and used across the internet.
I've used it in the past to give read-only anonymous access to a directory, and I could still fly around the world and securely mount the SFS share somewhere else. You probably don't want to mount an SFS share on insecure hardware that might have a keylogger, but it's a great way to have access to all your source code (and research papers in my case) from a friends house in another country. -
Re:An Easy Solution
I proposed this solution about 4 years ago to one of the gnome-vfs guys at a Helixcode party in San Francisco "back in the day".
So, did he answer "been there, done that" or "that's dumb"? Or did he just nod politely and suddenly act like he was being hailed from across the room? Only about a thousand people have had variants of the same idea; the two closest would be Farsite or SFS, but there are many others. One thing that's unique to your proposal, though, is the idea of sending every block to every node - creating a system that cannot possibly scale beyond a trivial number of nodes.
There's nothing wrong with blue-sky thinking, but when the sky is already crowded with planes and helicopters and blimps you should take some time to study them before repeating the mistakes their designers made ten years ago. It's also good to get the basics working or at least decently thought out before you start speculating about what extra buzzword-compliant ideas you can throw into versions two through ten. We already have Freenet to show us what can happen when people don't heed either of those lessons.
-
...or you can try sfsFrom the main page for SFS (Self-certifying File System):
SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere. Anyone can set up an SFS server, and any user can access any server from any client. SFS lets you share files across administrative realms without involving administrators or certification authorities.
-
Debian is supported, Windows is unsupportedHuh, troll, how...?
:-)My parents (both in their mid-sixtees) have a Debian Woody-based workstation (with KDE 3.0, OO 1.0 and Firefox) and a laptop that came with WinXP. I made it very clear that Windows is unsupported, end of discussion.
I've also spent hours explaining to them why free as in speech is important, and how morally corrupt MS is. They understand that they just can't ask me to support MS.
They are pretty happy with it. My mother likes it very much, she has few problems. Not only is she surfing, reading e-mail and stuff, she also uses Amaya to create web pages for her class. She use SFS to get them onto my machine. Dad's not quite so happy, because he has bought into that "I shouldn't have to learn anything to use a computer" crap. But I am getting him to realize how wrong that is (after all, he is a civil engineer), so things are improving.
I recently got Debian onto moms laptop, as I needed to borrow it. As far as I know, they are not booting WinXP a lot anymore, they are mostly Debian users.
Really, I would recommend that approach to everyone: Make them use the OS you think is good, and try to make that OS work well for them. You can do most administration tasks remotely by SSH.
-
what they all lack is clientside encryptionThe only remote filesystem i found where the en-/decryption of files is done on the client side is TCFS. Unfortunately, it seems to be not maintained any more (last news 13months old, linuxversion still uses 2.2).
All other "encrypting remote filesystems" encrypt only the filetransfer, not the filestorage (AFS or - if i understood the FAQ correctly - SFS). So the fileserver admin (or an intruder or trojan) is able to read served files cleartext.
What's required is a remote filesystem where the clients do not need to trust the service nodes for data integrity and privacy. If i did not miss something (please tell me!), the only option nowadays is stacking a local crypting fs on top of a remote fs, e.g. NCryptfs on top of NFS or AFS.
/graf0z. -
Check out SFS or CFS
The self-certifying filesystem or the cooperative filesystem might do what you want, though I believe they only run on unix platforms. The code is considered to be in the alpha stage, but apparently the maintainers have been using it for a while without losing files. On some platforms SFS (on which CFS is based) has the nasty habit of deadlocking the kernel from time to time. You might want to read their documentation, since this might not be a problem for what you're running on.
SFS
CFS -
SFS?
Haven't there already been other projects with similar design goals, like the Self-certifying file system? The authors of SHFS say it's a hack, which has a few drawbacks -- e.g., in generic write operations on non-Linux machines, a separate write() system call is used for each byte! Can anyone comment on the relative merits/demerits of the alternatives?
-
Try SFS
Not sure what you mean by ``distributed''. you should be a little more specific about what you want. However, SFS (self-certifying file system) is a good replacement for NFS, featuring privacy and authentication. Works on Linux, *BSD, MacOS X....
see http://www.fs.net -
SFS (Self-certifying File System)I would use SFS, the Self-certifying File System.
- "SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere. Anyone can set up an SFS server, and any user can access any server from any client. SFS lets you share files across administrative realms without involving administrators or certification authorities."
- Several of the SFS authors use SFS for their home directories without any problems. SFS has been in use for several years and we have never lost a file. That said, SFS should still be considered alpha software."
-
Self Certifying File System
I would use SFS, the Self Certifying File System. Assuming all the systems you are using are supported, it offers global, secure access to anything you care to export.
-
Self-certifying File System
Take a look at http://www.fs.net
... There was an article in the ;login Dec 2002 issue
"SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere." -
One nifty way to do it......is with the Self-certifying File System (SFS). Check it out:
SFS is a secure, global network file system with completely decentralized control. SFS lets you access your files from anywhere and share them with anyone, anywhere. Anyone can set up an SFS server, and any user can access any server from any client. SFS lets you share files across administrative realms without involving administrators or certification authorities.
http://sfs.fs.net -
PS - Wrong URL too
By the way, he got the URL wrong too - www.fs.net (SFS), not www.sf.net (sourceforge)
-
Re:Let me ask one question...
Why does the repository need to be public? In an era of very powerful client machines, why must we have a centralized database
Why do you assume that public implies centralized? The article author certainly didn't; that was actually one of the questions s/he was asking? If you look at systems like OceanStore or SFS, or even Microsoft's own Farsite, you'll quickly realize that your assumption is false.
-
Re:Hmmm, This and the PS3
-
NFS is REALLY insecure. But there are secure Alt.
NFS has a long history of insecurities.(Link takes a little while to load...)
Also in the article he claims: "You can reboot a server and the client won't crash." Maybe not crash but at least with Solaris (in my experience) you hang the entire system during the reboot. Sometimes it comes back and sometimes it doesn't.
For a secure alternative that runs on *BSD/Solaris/Linux w/(2.4 Kernels) try out:
Self-Certifying Filesystem.
The authors do warn that it is in alpha stage but also claim they have never lost a file. VERY cool project.
And of course as the OpenBSD Journal has noted, SysAdmin Mag is running an article on Tunneling NFS over SSH. -
Corrections, pointers, and cautionsA few things in the article deserve to be clarified. First, Lucas states that "One thing to note is that NFS uses the same usernames on each side of the connection." This is not accurate - NFS uses the same UIDs on both sides of the connection. If you don't have a unified UID space between your machines, you'll have
.. issues.Second, if you export NFS to the world, you're insane and deserve what you get. If you want remote filesystem access, use a secure protocol like the Self-Certifing Filesystem (SFS). SFS also avoids completely the problem of having a shared UID space.
Finally, his advice to mount your filesystems intr is good. But insufficient - also mount them soft, so that filesystem calls will eventually timeout if the server goes poof.
-
where are the secretsYou don't want to duplicate secrets. If possible, you don't want to transmit them all over the place either, though that's not so bad if done correctly. One way is to use a public key system, so that the secrets are stored on the client machines. Every server knows all the public keys, because they can be stored centrally on a keyserver or duplicated around the network; republishing them if they change is no big deal 'cause they're public. You could do this with OpenSSH.
If you perhaps do not trust the client machines, though, which you might not if they are Windows boxes, you would not want to use just public key crypto. You would also want to use a passphrase based system, and then you are back to having to have secrets on the servers, which need to be very carefully republished when they change. And you might not trust some of the servers. OpenSSH (and especially OpenSSH with the SRP patch) can do this, and it'll authenticate both the client *and* the server, so that both parties know they are connected with the entity they think they are connected to.
You might also want to look at SFS (a secure distributed filesystem based on NFS but with SRP authentication). Note that there are several projects all called SFS -- I'm thinking of the self-certifiying one. Then you can have central administration of server-side secrets. Probably some of the other projects called SFS would be good too, but I'm less familiar with them.
-
cryptfsThere is a cryptographic file system you can get for SFS. If you go to the download page, it's called cryptfs. Unfortunately, you have to install SFS first to compile cryptfs.
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.
-
cryptfsThere is a cryptographic file system you can get for SFS. If you go to the download page, it's called cryptfs. Unfortunately, you have to install SFS first to compile cryptfs.
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.
-
Re:Never heard of any such Cesium project...
I also don't understand what the purpose of keeping an OS project secret would be in an academic enviroment. Remember publish or perish?
Actually there's a whole bunch of reasons which make it hard to deal with a large system in an academic environment. Publish or perish is certainly a major contributor. But large systems just have so much icky overhead to make them work that, in terms of work-to-reward ratio, it's almost never worth it to do a complete system. Or feasible; we don't have enough people to write large quantities of production code. Successful systems projects (wrt an academic metric for 'successful'), for instance, the self-certifying file system use parts of other systems that people have built. It's a lot easier that way, and it's really useful when those other systems are free software.
Of course, there are major minuses to not having a system you can actually use day-to-day. A lot of the microkernel research, I'm told, was done by people who didn't 'eat their own dogfood'. They would boot up the system, run their benchmarks, then shut it off. This didn't capture problems which occur only after a few days of uptime.
By the way, you can check out what the operating systems dudes are actually doing at their website: Parallel and Distributed Operating Systems Group. -
SFS - DNS the way you want itsome guys at MIT developed a file system called SFS - Secure File System. Knowing how untrustworthy DNS really is, they used a novel authentication scheme by embedding the public key and hostname into a string called the HOSTID that's required to connect. Their implementation is based on NFS3, but the key-certifying scheme is applicable to everything.
-
If you want a secure distributed filesystem...
Try SFS the self-certifying filesystem. Here's a link. Its definately better than AFS.
-
Secure network file systemTake a look at SFS. It really does look like a secure way to do file sharing. Individual user are authenticated, the host itself is authenticated, and the traffic is encrypted. You do need NFSv3 support, as it is layered on top of it, but it is just about as fast as NFSv3, even with the security. Take a look.
For the latest Linux NFS patches, (to support V3), you'll want to go to nfs.sourceforge.net
-
Re:PKI and other issues
An interesting solution to this problem was just recently released: sfs, which allows separating the pki out from the connection protocol.