Linux On-Demand Network Access (LODNA)

Linux On-Demand Network Access (LODNA)

[Vlad C.]

Recent discussion on ReiserFS 4 has focused on the
advantages and disadvantages of VFS at the kernel
level versus the Desktop Environment (DE) level. I
believe network locations should be administered by
the kernel in a proposed framework called Linux
On-Demand Network Access (LODNA), which would achieve
seamless network integration regardless (or even in
the absence) of DEs, thus increasing usability.

INTRODUCTION:

When VFS is implemented at the  KDE/GNOME level, we
end up with the unfortunate situation where only
applications native to that DE can access its VFS
files. For example, Mozilla and Firefox (which are
GTK-based) can't access network locations set up under
KDE (see
https://bugzilla.mozilla.org/show_bug.cgi?id=298848).
Making an application aware of non-native VFS requires
serious amount of work, not only to use the other DE's
libraries, but also to embed miniature network clients
for every protocol the application supports.

The same problem appears in OpenOffice: even though it
can use the KDE filepicker, whenever  it accesses a
file on an SSH network location, a message pops up
saying "Protocol 'fish' is supported only partially.
Local copy of the file will be created."

If Mozilla/Firefox and OpenOffice, which are some of
the most popular applications and which have a strong
developer base, haven't yet been able to achieve
cross-VFS compatibility, you can be certain that other
applications are in the same or worse situation.

These two examples show why VFS at the DE level is a
temporary hack that only hides the need for such
functionality in the kernel. This hassle can be
completely avoided if the kernel provides standard I/O
functions for files in network locations
(ssh/webdav/ftp/smb/...) because opening and saving
network files would then become completely transparent
(i.e. no different from accessing a local file) from
the application's point of view. 

Having this functionality in the kernel would be a
huge usability plus: we would solve all these problems
in one swish, save application developers a lot of
time, and give users the peace of mind to know that
they can seamlessly access their network files no
matter what application they use.

PROPOSAL: Linux On-Demand Network Access (LODNA)

Users would be able to mount network locations under
directories they own. For example, to create a network
location on my home computer pointing to my work
computer (via ssh), I would do:
mount -t ssh username@remote.computer.com:~ 
/home/username/net/remote_computer

>From then on, whenever I change directory to
/home/username/net/remote_computer, I would be able to
see the files in my computer at work as if they were
local - no more need for fancy VPN!

Similarly, I would also be able to do:
mount -t smbfs username@remote.computer.com:~ 
/home/username/net/remote_computer
mount -t webdav username@remote.computer.com:~ 
/home/username/net/remote_computer
mount -t ftp username@remote.computer.com:~
/home/username/net/remote_computer

Advantages of LODNA:

1) Network locations would be fixed in the directory
tree, rather than float around in a DE abstraction
like fish:/ .
2) Remote files would be accessible by all
applications, even the shell.
3) LODNA would be independent of Desktop Environments
(although if present, they could provide GUIs for
things that could otherwise be done from the command
line). For example, KDE could use its existing "Add a
Network Folder" wizard to help users mount network
locations.
4) The user could give or deny other local users
access to his remote locations simply by setting the
permissions of the mount point (eg. chmod 700
/home/username/net/remote_computer).
5) LODNA would help users who want to access files on
their Local Area Network but who don't know the exact
name or IP address of the destination computer. Such
users could use KDE's Konqueror File Manager
(http://www.konqueror.org/) with the Smb4k
(http://smb4k.berlios.de/) plugin to discover all the
samba servers on their LAN. They could then simply
right-click on a  server/share and select "Mount",
which would take them to the "Add a Network Folder"
wizard.
6) LODNA would combine the transparency of NFS with
the flexibility of SSH/SMB/WebDav/FTP.
7) LODNA would allow users to build and manage their
own VPN client.

CONCLUSION:

Linux On-Demand Network Access (LODNA) is a proposed
kernel-based method for accessing network locations.
It would provide transparent, unified network access
to all applications and pave the way for highly
intuitive GUIs for managing diverse networks. As a
built-in, multi-protocol VPN client, LODNA would
greatly help employees who work from home, and be a
much needed step towards making Linux viable on the
desktop.

For now, LODNA is only a concept, but the pieces
needed to make it happen already exist - they just
need to be integrated into the kernel, perhaps as a
ReiserFS 4 plugin or by another method. I welcome your
suggestions!

Cheers,
Vlad


		
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.  
http://auctions.yahoo.com/

Re: Linux On-Demand Network Access (LODNA)

[Hans Reiser]

Please treat at greater length how your proposal differs from NFS.

Hans

Vlad C. wrote:

>Recent discussion on ReiserFS 4 has focused on the
>advantages and disadvantages of VFS at the kernel
>level versus the Desktop Environment (DE) level. I
>believe network locations should be administered by
>the kernel in a proposed framework called Linux
>On-Demand Network Access (LODNA), which would achieve
>seamless network integration regardless (or even in
>the absence) of DEs, thus increasing usability.
>
>INTRODUCTION:
>
>When VFS is implemented at the  KDE/GNOME level, we
>end up with the unfortunate situation where only
>applications native to that DE can access its VFS
>files. For example, Mozilla and Firefox (which are
>GTK-based) can't access network locations set up under
>KDE (see
>https://bugzilla.mozilla.org/show_bug.cgi?id=298848).
>Making an application aware of non-native VFS requires
>serious amount of work, not only to use the other DE's
>libraries, but also to embed miniature network clients
>for every protocol the application supports.
>
>The same problem appears in OpenOffice: even though it
>can use the KDE filepicker, whenever  it accesses a
>file on an SSH network location, a message pops up
>saying "Protocol 'fish' is supported only partially.
>Local copy of the file will be created."
>
>If Mozilla/Firefox and OpenOffice, which are some of
>the most popular applications and which have a strong
>developer base, haven't yet been able to achieve
>cross-VFS compatibility, you can be certain that other
>applications are in the same or worse situation.
>
>These two examples show why VFS at the DE level is a
>temporary hack that only hides the need for such
>functionality in the kernel. This hassle can be
>completely avoided if the kernel provides standard I/O
>functions for files in network locations
>(ssh/webdav/ftp/smb/...) because opening and saving
>network files would then become completely transparent
>(i.e. no different from accessing a local file) from
>the application's point of view. 
>
>Having this functionality in the kernel would be a
>huge usability plus: we would solve all these problems
>in one swish, save application developers a lot of
>time, and give users the peace of mind to know that
>they can seamlessly access their network files no
>matter what application they use.
>
>PROPOSAL: Linux On-Demand Network Access (LODNA)
>
>Users would be able to mount network locations under
>directories they own. For example, to create a network
>location on my home computer pointing to my work
>computer (via ssh), I would do:
>mount -t ssh username@remote.computer.com:~ 
>/home/username/net/remote_computer
>
>>From then on, whenever I change directory to
>/home/username/net/remote_computer, I would be able to
>see the files in my computer at work as if they were
>local - no more need for fancy VPN!
>
>Similarly, I would also be able to do:
>mount -t smbfs username@remote.computer.com:~ 
>/home/username/net/remote_computer
>mount -t webdav username@remote.computer.com:~ 
>/home/username/net/remote_computer
>mount -t ftp username@remote.computer.com:~
>/home/username/net/remote_computer
>
>Advantages of LODNA:
>
>1) Network locations would be fixed in the directory
>tree, rather than float around in a DE abstraction
>like fish:/ .
>2) Remote files would be accessible by all
>applications, even the shell.
>3) LODNA would be independent of Desktop Environments
>(although if present, they could provide GUIs for
>things that could otherwise be done from the command
>line). For example, KDE could use its existing "Add a
>Network Folder" wizard to help users mount network
>locations.
>4) The user could give or deny other local users
>access to his remote locations simply by setting the
>permissions of the mount point (eg. chmod 700
>/home/username/net/remote_computer).
>5) LODNA would help users who want to access files on
>their Local Area Network but who don't know the exact
>name or IP address of the destination computer. Such
>users could use KDE's Konqueror File Manager
>(http://www.konqueror.org/) with the Smb4k
>(http://smb4k.berlios.de/) plugin to discover all the
>samba servers on their LAN. They could then simply
>right-click on a  server/share and select "Mount",
>which would take them to the "Add a Network Folder"
>wizard.
>6) LODNA would combine the transparency of NFS with
>the flexibility of SSH/SMB/WebDav/FTP.
>7) LODNA would allow users to build and manage their
>own VPN client.
>
>CONCLUSION:
>
>Linux On-Demand Network Access (LODNA) is a proposed
>kernel-based method for accessing network locations.
>It would provide transparent, unified network access
>to all applications and pave the way for highly
>intuitive GUIs for managing diverse networks. As a
>built-in, multi-protocol VPN client, LODNA would
>greatly help employees who work from home, and be a
>much needed step towards making Linux viable on the
>desktop.
>
>For now, LODNA is only a concept, but the pieces
>needed to make it happen already exist - they just
>need to be integrated into the kernel, perhaps as a
>ReiserFS 4 plugin or by another method. I welcome your
>suggestions!
>
>Cheers,
>Vlad
>
>
>		
>____________________________________________________
>Sell on Yahoo! Auctions – no fees. Bid on great items.  
>http://auctions.yahoo.com/
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>

Re: Linux On-Demand Network Access (LODNA)

[Jeremy Maitin-Shepard]

I believe he is suggesting the addition of an sshfs, ftpfs, webdavfs,
etc. to the kernel, and allowing unprivileged users to mount these
filesystems.  (As a side note, I find it somewhat peculiar that he
includes smbfs in an example, since that is already implemented in the
kernel.)  Although he refers to possible implementation of these
facilities as reiserfs 4 plugins, it would seem far more straightforward
and useful to implement them as separate filesystems.  In fact, many of
these facilities already exist as filesystems for Linux.  For instance,
there is an sshfs program for FUSE, and FUSE already provides the
unprivileged mounting support mentioned in the proposal.

-- 
Jeremy Maitin-Shepard

Re: Linux On-Demand Network Access (LODNA)

[Vlad C.]

--- Hans Reiser <reiser@namesys.com> wrote:
> Please treat at greater length how your proposal
> differs from NFS.

I think NFS is not flexible enough because:

1) NFS requires synchronization of passwd files or
NIS/LDAP to authenticate users (which themselves
require root access on both server and client to
install)
2) NFS by definition understands only its own network
protocol.
3) NFS requires root privileges on the client to
mount. I'm not aware of a way to let normal users
mount an NFS partition other than listing it in the
client's fstab and adding the 'users' option... but
then changing fstab still requires root access.
4) Users have to contact their sysadmin every time
they want to mount a different partition, a different
subdirectory of the same partition, or if they want to
change the local mountpoint, all because the partition
and mountpoint are hard-coded in fstab.

On the other hand, I envision the following:

1) No authentication layer required other than the
authentication built into the protocol. All the user
needs is the DNS/IP address of the server, a username,
a password, a path on the server, and a local
directory they own to act as a mountpoint. Note that
the user's identity on the server is not tied to his
identity on the client, as it is the case with NFS,
but rather the user can chose which username to
"Connect As" when he performs the mount.
2) Support for multiple network protocols.
3) No need for root privileges when choosing what to
mount and where to mount. Some may say this is a
security risk, but I see it as improved usability.
After all, DE-level implementations like KDE's fish:/
don't require root privileges either. Nevertheless, I
think there should be some sort of switch where the
sysadmin can allow/deny user mounting on a global or
per user basis  (rather than a per fstab-line basis).

Reasons 3 and 4 for why NFS is not flexible enough
could also apply to the current Linux implementation
of smbfs, which leads me to believe that part of the
problem lies in the fact that users can't mount
locations that aren't explicitly listed in fstab. I
guess a per fstab-line basis of allowing mounts makes
sense when there are a finite number of devices, but
it doesn't make much sense when there are an infinite
number of network addresses. I'm just thinking out
loud here, but would it be possible to specify ranges
of addresses and directories using wildcards? Such a
line in fstab would look like:
*.myhost.com:/home/* /home/* nfs
rsize=8192,wsize=8192,timeo=14,users

In this case, users could do:
mount -t nfs host1.myhost.com:/home/username
~/remote_home

but they couldn't do:
mount -t nfs host1.myhost.com:/tmp ~/remote_tmp

After receiving several suggestions, it appears that
FUSE (http://fuse.sourceforge.net/) and the various
projects that build on it
(http://fuse.sourceforge.net/filesystems.html) have
the potential to do a lot of what I had envisioned
LODNA doing. Therefore, I realize that there's
probably no need for yet another VFS framework ;)
Nevertheless, I think there is room for improvement
when it comes to giving users more flexibility in
mounting network locations (as described above).

Thanks,
Vlad

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Linux On-Demand Network Access (LODNA)

[Hans Reiser]

You might look into SFS by David Mazieres, some concepts in it are
likely to interest you.

Hans

Vlad C. wrote:

>--- Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>Please treat at greater length how your proposal
>>differs from NFS.
>>    
>>
>
>I think NFS is not flexible enough because:
>
>1) NFS requires synchronization of passwd files or
>NIS/LDAP to authenticate users (which themselves
>require root access on both server and client to
>install)
>2) NFS by definition understands only its own network
>protocol.
>3) NFS requires root privileges on the client to
>mount. I'm not aware of a way to let normal users
>mount an NFS partition other than listing it in the
>client's fstab and adding the 'users' option... but
>then changing fstab still requires root access.
>4) Users have to contact their sysadmin every time
>they want to mount a different partition, a different
>subdirectory of the same partition, or if they want to
>change the local mountpoint, all because the partition
>and mountpoint are hard-coded in fstab.
>
>On the other hand, I envision the following:
>
>1) No authentication layer required other than the
>authentication built into the protocol. All the user
>needs is the DNS/IP address of the server, a username,
>a password, a path on the server, and a local
>directory they own to act as a mountpoint. Note that
>the user's identity on the server is not tied to his
>identity on the client, as it is the case with NFS,
>but rather the user can chose which username to
>"Connect As" when he performs the mount.
>2) Support for multiple network protocols.
>3) No need for root privileges when choosing what to
>mount and where to mount. Some may say this is a
>security risk, but I see it as improved usability.
>After all, DE-level implementations like KDE's fish:/
>don't require root privileges either. Nevertheless, I
>think there should be some sort of switch where the
>sysadmin can allow/deny user mounting on a global or
>per user basis  (rather than a per fstab-line basis).
>
>Reasons 3 and 4 for why NFS is not flexible enough
>could also apply to the current Linux implementation
>of smbfs, which leads me to believe that part of the
>problem lies in the fact that users can't mount
>locations that aren't explicitly listed in fstab. I
>guess a per fstab-line basis of allowing mounts makes
>sense when there are a finite number of devices, but
>it doesn't make much sense when there are an infinite
>number of network addresses. I'm just thinking out
>loud here, but would it be possible to specify ranges
>of addresses and directories using wildcards? Such a
>line in fstab would look like:
>*.myhost.com:/home/* /home/* nfs
>rsize=8192,wsize=8192,timeo=14,users
>
>In this case, users could do:
>mount -t nfs host1.myhost.com:/home/username
>~/remote_home
>
>but they couldn't do:
>mount -t nfs host1.myhost.com:/tmp ~/remote_tmp
>
>After receiving several suggestions, it appears that
>FUSE (http://fuse.sourceforge.net/) and the various
>projects that build on it
>(http://fuse.sourceforge.net/filesystems.html) have
>the potential to do a lot of what I had envisioned
>LODNA doing. Therefore, I realize that there's
>probably no need for yet another VFS framework ;)
>Nevertheless, I think there is room for improvement
>when it comes to giving users more flexibility in
>mounting network locations (as described above).
>
>Thanks,
>Vlad
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>
>  
>

Re: Linux On-Demand Network Access (LODNA)

[Vlad C.]

--- Hans Reiser <reiser@namesys.com> wrote:
> You might look into SFS by David Mazieres, some
> concepts in it are
> likely to interest you.

Thank you for your suggestion. I've taken a look at
SFS (http://www.fs.net/sfswww/), and I like its
emphasis on user-friendliness and security. It's a
toss-up between SFS and SSHFS
(http://fuse.sourceforge.net/sshfs.html), since they
allow non-root users to mount and they're secure.

I tend to lean towards SSHFS since it only needs to be
installed on the client (as opposed to SFS, which must
be installed on client and server). The server side of
SSHFS is the just sshd, which has been heavily tested
and works out of the box on most modern systems. SFS
also has some minor idiosyncrasies, like mounting
everything under /sfs and including cryptographic
hashes as part of directory names (both of which can
be overcome with symlinks). 

Best regards,
Vlad


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: Linux On-Demand Network Access (LODNA)

[Peter Staubach]

Vlad C. wrote:

>--- Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>Please treat at greater length how your proposal
>>differs from NFS.
>>    
>>
>
>I think NFS is not flexible enough because:
>
>1) NFS requires synchronization of passwd files or
>NIS/LDAP to authenticate users (which themselves
>require root access on both server and client to
>install)
>2) NFS by definition understands only its own network
>protocol.
>3) NFS requires root privileges on the client to
>mount. I'm not aware of a way to let normal users
>mount an NFS partition other than listing it in the
>client's fstab and adding the 'users' option... but
>then changing fstab still requires root access.
>4) Users have to contact their sysadmin every time
>they want to mount a different partition, a different
>subdirectory of the same partition, or if they want to
>change the local mountpoint, all because the partition
>and mountpoint are hard-coded in fstab.
>
>On the other hand, I envision the following:
>

Please keep in mind that these are restrictions of the current NFS
implementation and are not inherent in an NFS solution.

The implied need for flexibility is being addressed by NFSv4 and the
ability to understand multiple versions of protocols and multiple
protocols is already resident in the system.  We could do some work
to make it more transparent if desired, but it already works.

    Thanx...

       ps

Re: Linux On-Demand Network Access (LODNA)

[Hans Reiser]

Peter Staubach wrote:

> Vlad C. wrote:
>
>> --- Hans Reiser <reiser@namesys.com> wrote:
>>  
>>
>>> Please treat at greater length how your proposal
>>> differs from NFS.
>>>   
>>
>>
>> I think NFS is not flexible enough because:
>>
>> 1) NFS requires synchronization of passwd files or
>> NIS/LDAP to authenticate users (which themselves
>> require root access on both server and client to
>> install)
>> 2) NFS by definition understands only its own network
>> protocol.
>> 3) NFS requires root privileges on the client to
>> mount. I'm not aware of a way to let normal users
>> mount an NFS partition other than listing it in the
>> client's fstab and adding the 'users' option... but
>> then changing fstab still requires root access.
>> 4) Users have to contact their sysadmin every time
>> they want to mount a different partition, a different
>> subdirectory of the same partition, or if they want to
>> change the local mountpoint, all because the partition
>> and mountpoint are hard-coded in fstab.
>>
>> On the other hand, I envision the following:
>>
>
> Please keep in mind that these are restrictions of the current NFS
> implementation and are not inherent in an NFS solution.
>
> The implied need for flexibility is being addressed by NFSv4 and the
> ability to understand multiple versions of protocols and multiple
> protocols is already resident in the system.  We could do some work
> to make it more transparent if desired, but it already works.
>
>    Thanx...
>
>       ps
>
>
Peter, do you agree with his point that mounting should be something
ordinary users can do on mountpoints they have write permission for?

Do you agree that a systematic review of user friendliness would help
NFS?  Do you think that NFS should look at SFS and consider adopting
some of its features?

Hans

Re: Linux On-Demand Network Access (LODNA)

[Peter Staubach]

Hans Reiser wrote:

>Peter, do you agree with his point that mounting should be something
>ordinary users can do on mountpoints they have write permission for?
>
>Do you agree that a systematic review of user friendliness would help
>NFS?  Do you think that NFS should look at SFS and consider adopting
>some of its features?
>

I think that connecting to required data could be more easily done than
currently. I don't know about allowing file systems to be mounted without
some form of control or resource utilization controls however.

I do agree that the entire user experience associated with using and trying
to administrate an NFS network could stand a good, long, hard look.

Traditional tools such as the automounter were nice 15 years ago, but have
not evolved with the world, nor have the rest of the system tools for
monitoring and managing NFS clients and servers.

I could definitely envision better ways to handle things.  In the past,
many of the arguments against making things better were security related.
There has been strong (relative term) security available to NFS 
implementations
since 1997, but many vendors have not implemented it and many customers 
found
it difficult to deploy because the underlying tools were very difficult to
deploy.  Many of the vendors are now implementing the security 
framework, but
more work is required on the underlying security mechanisms, making them
easier to deploy.

With proper security, usable monitoring and management tools, and flexible
resource controls, then I wouldn't see why NFS mounts should be anything
special.

    Thanx...

       ps

Re: Linux On-Demand Network Access (LODNA)

[Hans Reiser]

Peter Staubach wrote:

> Hans Reiser wrote:
>
>> Peter, do you agree with his point that mounting should be something
>> ordinary users can do on mountpoints they have write permission for?
>>
>> Do you agree that a systematic review of user friendliness would help
>> NFS?  Do you think that NFS should look at SFS and consider adopting
>> some of its features?
>>
>
> I think that connecting to required data could be more easily done than
> currently. I don't know about allowing file systems to be mounted without
> some form of control or resource utilization controls however.
>
> I do agree that the entire user experience associated with using and
> trying
> to administrate an NFS network could stand a good, long, hard look.
>
> Traditional tools such as the automounter were nice 15 years ago, but
> have
> not evolved with the world, nor have the rest of the system tools for
> monitoring and managing NFS clients and servers.
>
> I could definitely envision better ways to handle things.  In the past,
> many of the arguments against making things better were security related.
> There has been strong (relative term) security available to NFS
> implementations
> since 1997, but many vendors have not implemented it and many
> customers found
> it difficult to deploy because the underlying tools were very
> difficult to
> deploy.  Many of the vendors are now implementing the security
> framework, but
> more work is required on the underlying security mechanisms, making them
> easier to deploy.
>
> With proper security, usable monitoring and management tools, and
> flexible
> resource controls, then I wouldn't see why NFS mounts should be anything
> special.
>
>    Thanx...
>
>       ps
>
>
I would encourage you to look at SFS.....  it fixes a lot, making adding
what Vlad asks for reasonable.

Re: Linux On-Demand Network Access (LODNA)

[Vlad C.]

--- Peter Staubach <staubach@redhat.com> wrote:

> Vlad C. wrote:
> 
> >--- Hans Reiser <reiser@namesys.com> wrote:
> >  
> >
> >>Please treat at greater length how your proposal
> >>differs from NFS.
> >>    
> >>
> >
> >I think NFS is not flexible enough because:
> >
> >1) NFS requires synchronization of passwd files or
> >NIS/LDAP to authenticate users (which themselves
> >require root access on both server and client to
> >install)
> >2) NFS by definition understands only its own
> network
> >protocol.
> >3) NFS requires root privileges on the client to
> >mount. I'm not aware of a way to let normal users
> >mount an NFS partition other than listing it in the
> >client's fstab and adding the 'users' option... but
> >then changing fstab still requires root access.
> >4) Users have to contact their sysadmin every time
> >they want to mount a different partition, a
> different
> >subdirectory of the same partition, or if they want
> to
> >change the local mountpoint, all because the
> partition
> >and mountpoint are hard-coded in fstab.
> >
> >On the other hand, I envision the following:
> >
> 
> Please keep in mind that these are restrictions of
> the current NFS
> implementation and are not inherent in an NFS
> solution.
> 
> The implied need for flexibility is being addressed
> by NFSv4 and the
> ability to understand multiple versions of protocols
> and multiple
> protocols is already resident in the system.  We
> could do some work
> to make it more transparent if desired, but it
> already works.

I've used NFS but I'm by no means an expert on its
bleeding edge functionality, so my comments might have
been a bit outdated ;) From what I've seen, NFS
provides excellent network transparency, and I'm sure
version 4 is progressing nicely towards supporting
more protocols and reducing administrative overhead.

Best regards,
Vlad


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: Linux On-Demand Network Access (LODNA)

[Alan Cox]

Take a look at FUSE, it should be able to do all you need