dbz@swbatl.sbc.com (Dave Zumbro 5-3022 11-Y-1) (08/10/90)
Does anyone know if Sun changed the NFS protocol between SunOS
4.0 and subsequent releases? Specifically, was the uid and the
gid sent across the network, from client to server, when a
'chown' or 'chgrp' was performed on a file. And now ( > SunOS
4.0.3), is only the uid sent on a chown with the gid set to -1,
and only the gid sent on a chgrp with the uid set to a -1 (65535
or 0xffff).
I raise these questions because we have a Tandem Integrity S2
we're using as a file server for several many Sun SPARCStation
1+'s. And when ever the owner of a file is changed from the Sun
side, the uid is set as desired, but the group id gets changed
to 65535 (or a -1). The opposite happens when the gid is
changed, i.e., the gid is set as desired but the uid gets set to
65535. When the Sun acts as the server the file ownerships are
what would be expected after a chown or chgrp.
This get more interesting ... we've set up a matrix of several
different vendor's UNIX systems where each system is a client of
each other system, and each system is also is a server for every
other system ... ( save the Pyramid) ... As follows
clients --> | Sun Tandem PC Pyramid
|
servers OS-> | SunOS 4.1 Non-Stop Interactive OSX 4.4
v | & 4.0.3 UX A02 Sys V.3.2
------------------------------------------------------------------------
Sun | OK OK OK OK
|
Tandem | chown sets OK OK --
| gid == -1,
| chgrp sets
| uid == -1
|
PC | OK OK OK --
|
Pyramid | OK -- -- --
Now as I recall, somewhere around SunOS 4.0.x, the "nobody" uid
and gid was changed to -2 (65534) -- there was a big deal made
of it in one of the quad-zillion "Read Me First" TN's that came
with our systems. Could it be that Sun decided to use -- in a
more "secure" NFS protocol -- a -1 to indicate an unsent or
unspecified, i.e., secure uid/gid and that that's why the
"nobody" uid/gid had to change? And that Tandem's Non-Stop UX
A02 (equiv. to Sys V.3.1.x) sees the -1 as a changed gid or uid
along with the changing uid/gid?
Well. That's exactly what we believe is happening. In fact we
used etherfind and an interesting uid/gid (-7 or 65529) to test
our theory and indeed the Tandem always sent both the uid and
gid on either a chown or chgrp. The Sun's only sent both when
both were changed (i.e., chown 65529.65529 testfile). When only
the uid was changed, only the uid was sent followed by 0xffff or
-1 were the gid was in previous packets. The same occurred for
chgrp's on the test file, a -1 appeared where there the uid
would have been.
Interesting ... no? Anyone care to comment?
Dave Zumbro
Southwestern Bell Telephone Company
314-235-3022 or 314-529-7775
texbell!dbz@swbatl.sbc.com or
...uunet!{texbell!|sbctri!}swbatl!dbzws@tools.uucp (Wolfgang Solfrank) (08/12/90)
I quote from RFC 1094: 2.2.3. Set File Attributes ... The "attributes" argument contains fields which are either -1 or are the new value for the attributes of "file". and 2.3.6. sattr ... A value of -1 indicates a field that should be ignored. But beware, there is a note in 2.2.3: Note: The use of -1 to indicate an unused field in "attributes" is changed in the next version of the protocol. -- ws@tools.uucp (Wolfgang Solfrank, TooLs GmbH) +49-228-230088