You might look into SFS by David Mazieres, some concepts in it are likely to interest you.
Hans Vlad C. wrote: >--- Hans Reiser <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
