Slashdot Mirror
Mount Remote Filesystems via SSH
eval writes "Ever wanted secure access to your files at work or school, but didn't have the necessary permissions or were thwarted by a firewall that allowed ssh access only? The SHFS kernel module allows you to mount directories from machines to which you have shell access. File operations are executed as shell commands on the server via SSH (or rsh). Caching keeps it reasonably fast, and remote commands are optimized based on the server's OS."
This is a good idea, however there is one problem with the way that the problem is presented above:
If you're at work or school, are you really going to be able to insert a kernel module on the machine you're on? Generally I would think that you do not have sufficient permissions on the local machine.
A new feature is just a bug waiting to happen. And vice versa.
What are you talking about? This makes a remote filesystem appear local, and all local commands work accordingly (i.e. edit a file, play an mp3, etc). With sftp you'd have to sftp a file down to do an operation on it, and then sftp it back up again afterwards, etc/
I've used lufs with the sshfs and it works great, I've even done compiles on a remote filesystem this way-- you simply cannot do that using just sftp/scp.
-- I speak only for myself.
Create VPN with freeswan or ppp over ssh, mount remote host from VPN.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Filesystems should be handled by the operating system, not the window manager.
I think technically, I'd rather see LUFS add this caching and do better. I really think SSH isn't something that should be in the kernel, and it isn't really necessary for performance reasons.
Litigious bastards
I just have to reply...
/.???
Having come from the world of satan (windows) and now firmly embedded in the world of linux I feel qualified to make this observation:
This is EXACTLY "what is wrong with open source". Not the software, not the thousands of dedicated people who contribute countless hours doing something as a labor of love. But the attitude that usability and ease-of-use are STUPID and not worthy of anyone's time.
To paraphrase: "If you're too lazy to do it using the extremely flexible but very arcane tool we have developed for you, you don't deserve to use linux."
Aside from the fact that this actually makes it easy to do something WITH the files, it also makes it substantially easier to get the files in the first place.
Also, anyone that knows anything about security knows that one of the main reasons security is circumvented is because of inconvenience. This removes that possibility.
Seriously, if you don't want to use it fine. But why take shots at it for the sake of looking l33t on
In the Hurd all the filesystems are done by userspace programs called "translators". So to access your local filesystem you have an ext2 translator which accesses it. You can write your own translators - I believe they have a system to access remote systems via FTP.
Both fish/gnome-vfs and the kernel module system seem wrong to me. With kernel modules you have to be root to load them, but on the other hand its bad to be remaking the wheel by rewriting the filesystem in user space (plus, it only works with programs that are designed to use it).
It would be nice if the kernel module was added to the main kernel and offered as a "standard" system where nonprivileged users can mount their own filesystems from userspace daemons - Linux is kind of paranoid about non-root users mounting FSes. It would appear to provide the advantages that the Hurd approach brings, while keeping the higher performance of a monolithic kernel (having all FSes in user space like Hurd does seems like a bad idea performance wise)
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
At the office I'm working at (contract job) they are extremely anal retentive. They disallow most outgoing connections, SSH included. People are pretty much limited to web browsing. Not a problem, however, since they allow a secure connection on 443. I just configured my router to redirect 443 to 22 and I can connect to my server.
Why does any software announcement that's posted here always bring out a bunch of elitist trolls? Oh, that's right - because it's not good enough unless it's yours.
Do you know the authors of shfs, their ages, and what classes they're taking? Have you even downloaded the driver? Compiled it? Actually used it? Have you tested it, exprienced crashed, and therefore empirically come to the conclusion that it's "dangerous"? Or do you just like to play the role of Slashdot nanny?
Wait, don't answer that. I really don't care.
*You* should care, however, that you come off looking like a frustrated little prick by shitting on other people's work - for no reason other than to hear your own voice. Nobody wants to read your little pride-ridden, hyper-competitive, and overtly paternalistic little diatribes, no matter how much you think you enjoy writing them.
Anyway, lighten up and take the post for what it is. And in the future, if you can't say at least one reasonably positive thing about someone else's hard work - do the world a favor and just shut the bloody fuck up.
I set up LUFS last night, and blithely opened a Nautilus window to a mount-point I'd created (to a VERY remote SSHFS-mounted machine). Big mistake.
I had forgotten, of course, that I had Nautilus turned on to do all its previews, subdir counting, etc. on local files - which of course it was treating this mount point as. And I cursed gnome-vfs2 for not automatically sensing the "remoteness", by reading the list of system-wide mount points and detecting which filesystem was handling the directory into which I'd gone.
KDE faces a similar problem, ultimately. Until we see "kdesh" or some sort of LD_PRELOAD to offer ioslaves to traditional UNIX utilities, there will be a rift between the well-integrated solutions that KDE and GNOME offer, but which don't interact with lower-level utilities, and the kernel/hybrid solutions which don't provide information to any layer higher than they are (or worse, which are ignored by that higher layer, because of NIH syndrome).
SHFS is not the wrong answer. If it has caching and LUFS lacks it, maybe some of that code will migrate into LUFS. That's the entire point of open source, people - let the better project win, not just the more established one. But ultimately, neither project is the answer I favor, until the people at work on these various layers of VFS switching start to accept that other peoples' work may be running on the same system their code is.
Nothing worth doing is worth doing today.
You'd have to have rules on how the mounting would be done: only mounting on directories owned by the user for example (to stop people doing things like mounting over
These are really implementation details though. They exist because they rely on the idea that "only root can mount filesystems". But I think that the ability for ordinary users to mount filesystems would be really useful. And thinking of it as a concept, I cant really see any logical reason why ordinary users shouldnt be allowed to do it.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
LUFS or FUSE would be the module you're talking about, which allows you to do filesystems in userspace, and can let users mount them. So Linux can do all three: kernel modules for lean, fast, "real" filesystems, LUFS or FUSE for "exotic" filesystems that shouldn't be in the kernel, and kioslaves and gnome-vfs for those who like reinventing the wheel and want to further bloat their favorite GUI library.
Litigious bastards
Mapping most urls to files isn't a great solution, but neither is mapping files to urls. How do you get a directory listing? How do you change permissions? Consider FTP: do you make a new connection for each URL, or do you keep the connection open for a while in hopes of getting another? Mounting makes sense when there's overhead in establishing a connection, be it parsing a filesystem or making a remote connection.
I guess what I'm saying is that a URL library (IOSlaves and gnome-vfs) is nice to have, and a file system (LUFS, FUSE) is nice, but they shouldn't be one and the same. The URL library can be used for browsers, downloaders, etc, but the filesystem and only the filesystem should be used for naive tools that want to run on a local filesystem.
Litigious bastards
Then again, KDE also works in *BSD, Solaris, HP-UX, and even Windows, to name a few. Writing kernel modules that work for every one of these systems would be a bit of a hassle, no? It might not even be possible in a few of these.
If someone were to implement all of these systems in the kernel, then KDE/GNOME, etc. can already them. In the mean time, this seems to be the best compromise between functionality and portability.
OR... a pipe or socket.
/dev/uld/cdda:scd0.raw /dev/uld/cdda:scd0.a
/dev/uld/cdda:scd0.a
/lib/modules/streams/vorbisenc.so -oq=5,oggwrap /dev/uld/cdda:scd0.a
/dev/uld/cdda:scd0.a > "KMFDM - Waste.ogg"
But as to not being seekable, etc: that's why we have the distinction in the first place!
For things that aren't like a file, they shouldn't be a file. We need appropriate metaphors for things that are not flat and seekable.
Duh character devices aren't seekable, that's the POINT. In fact, upon further reflection: the reason why a CD-filesystem is a bad idea is because only one process can use it at a time!!! (^_^;;;) Making some resource a filesystem implies that it can deal with at least concurrent access, right? I'm not saying you can't do it, but I don't think it's a good idea because it doesn't really get you anything special.
After further reflection, the cd-extraction "device" almost begs to be a character file. Send it an ioctl (with a silly little command line util), then start slurping it into oggenc. The "cdparanoia" device... you might use it like this:
$ cddactl --extract 1[1:30]-3[4:00]
oggenc [ some stuff ]
In this case, cdda:scd0.raw is the file that accepts the ioctls, and cdda:scd0.a is a magically created char device corresponding to your request to read a range from the CD, and data will only start appearing from there once all other requests have been fulfilled (otherwise you get EAGAIN on read()). I pretend that uld is a filesystem exported by a magic kernel module that allows user-space libs to do some grunt work and provide device files as needed.
Perfect way to queue up a bunch of jobs; just spawn a bunch of oggencs in parallel on the file requests, and let the kernel wake up the right process to do it.
Or you could do something evil like this:
$ streamctl --push
Then:
$ cat
That is definitely in the spirit of Unix!
And whatever happened to STREAMS? That would be a perfect way to take cdparanoia + ogg and roll it into a OS abstraction.
I'm talking about generic "uber-character devices" for asyncronously and syncronously available data, and a way to get at their individual ioctls without having to write whole C programs.
Some kinda standard for that would kick a large amount of ass, especially if its easily accessible from user space.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON