Problem with NFS and quotas

[barmar@Think.COM (Barry Margolin)]

    Date: Wed, 25 Mar 1992 13:39 EST
    From: SJAMESON@FERGIE.dnet.ge.com (Stephen M Jameson)

    Received: by fergie.DECnet (utk-mail11 v1.7) ; Wed, 25 Mar 92 13:38:09 EST
    Received: from weegie.ATL.GE.COM by fergie.ATL.GE.COM (5.61/GEA Sun server 2.4) with SMTP
	    id AA23801; Wed, 25 Mar 92 13:38:05 -0500
    Date: Wed, 25 Mar 92 13:38:05 -0500
    From: sjameson (Stephen M Jameson)
    Message-Id: <9203251838.AA23801@fergie.ATL.GE.COM>
    Received: by weegie.ATL.GE.COM (4.1/SMI-4.1)
	    id AA13378; Wed, 25 Mar 92 13:38:02 EST
    To: slug@ai.sri.com@aitgw.DECNET
    Subject: Problem with NFS and quotas
 
    Hello again,
 
    Thanks to all who responded to my earlier request for information about
    transferring file service over to a Unix box.  I have an additional problem
    which somebody may have some insight into.  The administrators who run the Unix
    system are balking at approving the arrangement because they claim that NFS has
    no mechanism for supporting file space quotas, and so a Symbolics user could
    overflow the file system and crash the server [in theory, and as you well know,
    system administrators think like military commanders -- in possibilities rather
    than probabilities].  Is there in fact no way for Genera/NFS to ensure that
    when a user writes files to the Unix system from a Symbolics, he or she does
    not exceed the quota established on the Unix system?  If there is no way, then
    I have to wait until they can install an independent Unix partition before I
    can even begin testing.
 
If quotas are enabled on the file server, then I think it will report an
error if the user tries to exceed his quota.

If the servers implement the Sun RPC-based rquotad server, it should be
easy to implement a Symbolics client for this (translating the spec in
/usr/include/rpcsvc/rquota.x to Symbolics RPC should be
straightforward).  And then you could patch the appropriate NFS routines
to call it (for instance, you could call it before closing an output
file) and signal an error if the user exceeds his quota.

But if your administrators only deal in absolutes, then Symbolics
clients open a whole can of probabilities.  The NFS protocol has weak
security, and there's no security on a Symbolics workstation, so there
are many opportunities for users to bypass most NFS checks.  For
instance, the NFS protocol depends on the client to do password checks
and then reliably include the userid in the request packets; it's a
trivial change to the Symbolics NFS software to bypass the password
request or to put someone else's userid in the request packets.  To
relate this to Unix administrators, a Lispm user is effectively a
superuser on his workstation, and kernel patching is trivial.

                                                barmar