lkml.org 
[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux On-Demand Network Access (LODNA)
    --- 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/

    \
     
     \ /
      Last update: 2005-07-13 01:55    [W:4.105 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site