File protection & Why NFS?

[Barry Margolin <barmar@THINK.COM>]

    Date: Fri, 31 Mar 89 13:40:33 EST
    From: MILLER@vax.cam.nbs.gov

      We've got DNA and can access vax files pretty straightforwardly
    (usually), but (users on) the vax cant get at the symbolics.  My guess
    is that it would be the same with TCP/IP & Suns.  We intend to get TCP/IP soon
    and I'm wondering whether we should consider NFS too.  Am I right in
    assumming that with NFS this becomes bi-directional, ie. the suns can
    access the symbolics file systems too?  If so, NFS seems relatively
    useless for the regular symbolics users but pretty good for the
    occasional users who normally work on SUNs.  Is there anything
    else it provides that I should know? 

NFS is hardly useless to the regular Symbolics users.  Without it, the
only protocol that the Lispm can use to access Unix files via TCP/IP is
FTP.  FTP is better than nothing, but it is a minimal protocol, whereas
NFS is designed with networked file systems in mind.

      If the above is correct and we do decide to get NFS, then I suppose
    its high time to learn about the Rel.7's protection schemes.  Actually
    even w/o NFS; re telnet: `User JOE BLOW is not known. Shall I just
    invent a user named JOE BLOW and give this user access to everything?'
    I haven't yet done my homework on the protection scheme; Anybody got any
    suggestions/warnings? 

Unfortunately, the NFS protocol doesn't provide any way to integrate
into the Symbolics file protection scheme.  It has no provision for
transmitting passwords, for example.  Among a group of Unix machines,
NFS access control works by having a list of trusted hosts and requiring
that connections come from privileged UDP ports (on Unix, only the
kernel and superuser programs are permitted to use ports 512-1023).
User authentication is supposed to be performed by the client host, and
the server trusts the client not to lie about the user identity.  If you
allow a Lispm to be an NFS client there's no way to prevent it from
pretending to be another user.

In other words, a Lispm NFS server doesn't have any way to perform user
authentication, and a Lispm client can't be trusted.  This works well in
an open environment where everyone trusts everyone else on the local
network.  But it doesn't work in an environment with potentially
malicious users. 

An upcoming revision of the NFS protocol does provide a better scheme
for user authentication, involving DES encryption.  Additionally, MIT
Project Athena has integrated NFS with their Kerberos authentication
protocol; I haven't yet heard of a Lispm implementation, though, but it
seems to me like there would be Lispm users at MIT who would be
interested in access files on Athena machines.

                                                barmar