[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux On-Demand Network Access (LODNA)
You might look into SFS by David Mazieres, some concepts in it are
likely to interest you.


Vlad C. wrote:

>--- Hans Reiser <> 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
>2) NFS by definition understands only its own network
>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:
>** /home/* nfs
>In this case, users could do:
>mount -t nfs
>but they couldn't do:
>mount -t nfs ~/remote_tmp
>After receiving several suggestions, it appears that
>FUSE ( and the various
>projects that build on it
>( 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).
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-13 03:24    [W:0.057 / U:0.464 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site