mouse@mcgill-vision.UUCP (der Mouse) (11/19/87)
In article <850@winchester.UUCP>, djl@mips.UUCP (Dan Levin) writes: > In article <32169@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: >> In some other article, someone writes: >>> No. NGROUP [...] kernel ucred (user's credentials) [...] >> [...] credentials are used when the kernel makes an RPC call [...] > [the RPC structure has a field for this number, but Sun NFS has 8 > hardcoded into it.] Interesting that the leading implementation of a > supposedly public domain protocol doesn't follow the spec... That's not the only way in which it doesn't follow the spec. I wrote an NFS server for 4.3 and observed that I kept getting 65535 in unused fields of sattr structures instead of -1. It seems that Sun NFS (I can't check real Sun source, but this *is* true of mtXinu's NFS) uses uid_t and gid_t in its vattr structure to hold UIDs and GIDs, for example. The nfssattr structure (the NFS spec's sattr structure) uses u_long. Copying is done by simple assignment. A null vattr structure, therefore contains (uid_t)-1 in an unused UID field. This (see types.h) is (unsigned short int)-1. Assign this to u_long (unsigned long int) and what do you get? That's right, you get 65535, not -1! This is true of mtXinu 4.3+NFS and therefore, presumably, was true of Sun NFS at some time. Can anyone say whether it is still the case? Can anyone explain how come this bug was missed in the first place? It would seem fairly easy to detect, for you do a chmod on a remote file and the server sees 65535 rather than -1 and it sets the owner uid and gid to 65535, instead of leaving them unchanged. Wonderful. Or does Sun's server code do what I had to make my server code do, and map 65535 into -1 (thus effectively meaning you can't use uid 65535)? Why couldn't they have implemented what their spec says?! der Mouse (mouse@mcgill-vision.uucp)