Re: Linux On-Demand Network Access (LODNA)

[Hans Reiser <reiser@namesys.com>]

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 
>
>
>  
>

-
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/