Slashdot Mirror
Experiences and Thoughts on SHFS?
eugene ts wong asks: "I was looking over SHFS, & I thought that this seems like a very good software package. If I understand it correctly, then it should be the defacto way to mount shares across a network. I never heard of it till today, though. What do all of you think of this? What kinds of experiences do you have? I am interested in hearing some of your stories. I heard that NFS isn't secure. How do they both compare? Would you recommend SHFS for small, medium & large businesses?"
Secure Sneaker Net
Two feet
Write Only Floppy Disk.
or more to the point why do you think its secure ?
it all comes down to trust...
do you trust the network your pluged into ?
how about the people who are selling that VPN ?
I surgest that you have a look at IPSec
it works on winXP linux solaris BSD's and then find a Networked File System that is high performance
regards
John Jones
I wanted a transparent way to access my remote files over SSH since it's the only external access I trust and came upon SHFS a couple of weeks ago.
.ko module built for 2.6 that the install process copies to you lib/modules directory didn't work. There was however a .o as well built for 2.6 that worked great after I copied it manually.
It has worked out really nice and I now don't have to do the scp or SFTP dance all of the time to edit files on a remote box.
One thing I came across though during "make install" under 2.6 is that the
I tried it, and I found it to be a bit unreliable. This was last fall... Random accesses on files were slow, and frequently it hung, leaving me with orphaned partitions I couldn't umount. Otherwise it worked ok -- I mean, it was easy to configure and whatnot, but performance wise when I tried it it was found lacking.
i had the same results more than a year ago. Eventually I settled on emacs + tramp which does a suitable job of allowing me to edit remote files over SSH with little pain.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
I have been using shfs for a few weeks now, and here are the pros and cons with my limited experience with it.
Pros:
(i) mounting remote filesystems over ssh is great, as you don't have to worry about opening up new ports.
(ii) read-only performance is good (I haven't had any problems).
Cons:
(i) definitely *buggy* (do not even think of using this for mounting partitions w/ critical data). For e.g., I mounted it read-only and by mistake opened a file with vim. When I tried to !wq, vim refused to write (obviously!), and I just escaped with a q!. Much to my chagrin, the file was gone--- I later figured that this was not a random bug; it was repeatable.
(ii) write performance (across a 1Mbps DSL conn.) *sucks*!
sounds a lot like LUFS ( http://lufs.sf.net ) which lets you mount remote filesystems via SSH, FTP, and several other novel protocols.
I tried using shfs but it didn't work very well (YMMV, I'm running a Gentoo 2.6.3 kernel) with my system. Frequent timeouts and the program had problems unmounting shfs mounts. I recently switched to using the "FISH" feature in KDE (fish://username@host/path_to_stuff/) and that has worked fairly well for my purposes.
i have been using it for months at home. works great on the home wireless network. well, up until i switched to using my 15" powerbook.
despite being quite excited about the possibilities, i'd never run this in a production environment. alot of people run down nfs for being insecure and sucky on any number of levels. i have to say, we had a very active messaging system behind a very high profile website use nfs for two years due to a combination of stupid developers and vendor going out of business. it NEVER broke. and we were churning 100's of thousands of files over nfs per day.
eventually i had to stop bringing it up in meetings cause it never broke. of course YMMV, mine sure did.
The place where I work is a UNIX shop, we use NFS all the time, because it operates reliably between various UNIX flavours. Every vendor has a robust implementation. We share terabyte-sized file systems, with no problems whatsoever. If you are worried about the security implications of NFS, there are other ways to combat them.
Write Only Floppy Disk... That means you can write, but you can't ever read, right?? Then, I suppose your data will be safe no matter what!
I've been using ntp on all the machines, but it doesn't seem to help much, there is still enough drift to cause make to fail. I'm not using any of the machines as an ntp server - though I have been thinking about that. Would that help? Especially given that one group of machines is rather a longish network trip from the rest (though only about three blocks in euclidean space).
I am not familiar with shfs other than a brief read of the website and this thread.
w/r/t NFS security, NFSv4 should solve most if not
all of the problems. Fundamentally two things always bothered me about NFS security.
RPC - NFS makes heavy use of sun-style RPC, requiring you to use the RPC libraries and the portmapper. This stuff has a bad reputation for security problems, eg, buffer overflows, and there is a lot of it, and it runs on random ports so it's difficult to filter/firewall/tunnel it.
no user credentials - NFS through V3 doesn't provide any user credentials - root on the client has access to all users' files on the mounted filesystem. There's no server-enforced security.
NFSv4 fixes the RPC/multiple ports problem.
I don't know about the user credential problem but i bet it fixes that too.
On to the quick-and-dirty:
In the past, I've set up a samba server and used the linux smbfs client to access it, and tunneled the whole business over SSH. It worked reliably, to the limited extent that i tested it (YMMV).
I don't really remember how well it performed - it was more of a proof-of-concept for me.
I've been using shfs to connect to my uni ssh server to access my files from home for about 6 months now, no problems at all (with both 2.4 and 2.6 kernels).
Would highly recommend it.
It's a pain in the butt, but you can at least fix the ports for NFSv3 in order to firewall:
/sbin/rpc.mountd --port ${RPCMOUNTDPORT}
/sbin/rpc.statd --port ${LISTEN_PORT}
/etc/modutils/nfs (or whatever works on your distro to set module params):
In your init:
And in
options lockd nlm_udpport=4001 nlm_tcpport=4001
For the above, be sure to run update-modules after in deb. Then afterwards, allow "RPCMOUNTDPORT, LISTEN_PORT, and udp/tcp ports 4001 (or whichever you choose) through the firewall.
If you only need to browse your shfs shares and read some data here and there, then go for it. But for heavier usage and especially if you need to write data... NO WAY. Check out the shfs source code if you need to find out, why. The write routine erm... could be better.