🚀 go-pugleaf

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

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

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