les@chinet.chi.il.us (Leslie Mikesell) (02/02/91)
I just discovered the following "interesting" behaviour in the version of HDB uucp shipped with AT&T's SysVr3.2: If you uucp a new copy of an existing file and (1) the new file is shorter than the old one and (2) the directory containing the file is not writable by uucp, the file is not truncated to the new length but the new contents overwrite the corresponding portion of the existing file. Les Mikesell les@chinet.chi.il.us
tedga@pandora.ism.isc.com (Ted Garrett) (02/06/91)
In article <1991Feb02.034416.3383@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >I just discovered the following "interesting" behaviour in the >version of HDB uucp shipped with AT&T's SysVr3.2: >If you uucp a new copy of an existing file and (1) the new file >is shorter than the old one and (2) the directory containing the >file is not writable by uucp, the file is not truncated to the >new length but the new contents overwrite the corresponding portion >of the existing file. > >Les Mikesell > les@chinet.chi.il.us Indeed this is 'interesting'. I've never had uucp override file or directory permissions on me, and I operated AT&T system V release 3.2.2 extensively using uucp for over a year. But then again, I usually restricted execute permissions for the directory also. uucp is a PROGRAM, not a user. Therefore, if the directory is not writeable, but the file is, AND the directory in question IS writeable by the person who requested the transfer, uucp SHOULD be able to write to the directory and file. ================================================================================ ____/| | These opinions are mine. Mine alone. | Ted Garrett \'o.O' | Don't you DARE try to blame my company | tedga@pandora.ism.isc.com =() ()= | for them. | Interactive Systems Corp. U | "Just 'cause ya got the money don't mean | Santa Monica, CA, USA Pth! Ack!| ya got the right!" Motorhead | ================================================================================ =============================================================================== ____/| | These opinions are mine. Mine alone. | Ted Garrett \'o.O' | Don't you DARE try to blame my company | tedga@pandora.ism.isc.com
les@chinet.chi.il.us (Leslie Mikesell) (02/07/91)
In article <1991Feb06.062553.15422@ism.isc.com> tedga@pandora.ism.isc.com (Ted Garrett) writes: >>I just discovered the following "interesting" behaviour in the >>version of HDB uucp shipped with AT&T's SysVr3.2: >>If you uucp a new copy of an existing file and (1) the new file >>is shorter than the old one and (2) the directory containing the >>file is not writable by uucp, the file is not truncated to the >>new length but the new contents overwrite the corresponding portion >>of the existing file. >Indeed this is 'interesting'. I've never had uucp override file or directory >permissions on me, and I operated AT&T system V release 3.2.2 extensively >using uucp for over a year. No, perhaps I didn't make this completely clear. The destination *file* is writeable by uucp, but not the directory which contains it. Thus it is not a security problem. The problem is that in this situation, the existing file is not truncated back to the length of the new verson. There is no error message or any indication of a problem, yet you are left with a file whose contents are not what you sent. Obviously uucp prefers to unlink the old copy and replace it with the new, but tries a second method when that isn't possible. Since SysVr3 doesn't have a documented method to truncate a file to an arbitrary length, the correct solution would be to truncate the existing file back to 0 length, then write in the new contents. >But then again, I usually restricted execute >permissions for the directory also. uucp is a PROGRAM, not a user. >Therefore, if the directory is not writeable, but the file is, AND the >directory in question IS writeable by the person who requested the >transfer, uucp SHOULD be able to write to the directory and file. In the context of permissions, uucp is a user since the programs run setuid. However, that doen't really relate to the problem, since the file in question was writeable by everyone. There is another problem that appeared in SysVr3.1 that apparently has something to do with security. If you start up uucico under root's id, (either uucico itself or uusched must be executed directly - it's different if you execute uucp or uux and they start uucico) and you receive a file which must have two levels of directories created to accept it, the transfer will fail. However, the directories are created and repeating the request will succeed (since the directories now exist. You can test this on your system with a command like: uucp -r remote!file /usr/spool/uucppublic/foo/bar/file (where you are sure the foo and bar directories don't exist). Then watch what happens, using "/usr/lib/uucp/Uutry -r remote" when you are logged in as root. Then try it again... This problem is not as esoteric as it sounds, since the commonly used "uuto" script generates destinations three directories under uucppublic. If those directories have been deleted by the cleanup script, and the sending system doesn't make the connection, then if the receiving system starts its uucico under the root id (either directly or by running uusched from root's crontab), you will lose the first file. Les Mikesell les@chinet.chi.il.us
det@hawkmoon.MN.ORG (Derek E. Terveer) (02/12/91)
les@chinet.chi.il.us (Leslie Mikesell) writes: >There is another problem that appeared in SysVr3.1 that apparently >has something to do with security. If you start up uucico under >[... description of 2+ level directory creation causing failure] Aha! Yes, i have seen this problem before and never got around to tracking down the exact reasons for it. I did notice that it failed when directories were created. BTW this is present in Esix 5.3.2-D. derek -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG -- U of MN Women's Lax I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots