At 8:12 AM -0500 3/16/00, lane @ DUPHY4.Physics.Drexel.Edu wrote:
>"Craig A. Berry" <[EMAIL PROTECTED]> writes:
>> As I reported earlier, taint.t was failing at test 10.  The reason
>> has to do with how /tmp is now handled by the C RTL.  The test would
>> determine that /tmp is a world-writeable directory, which is true for
>> recent versions of the C RTL that treat /tmp as sys$scratch.
>
>Well, I don't know about you, but I *don't* have sys$scratch: pointing
>to a "world" writable directory.  That would be unusual on VMS.
>Writable by the owner, yes.  Writable by the world, no.  Gets around
>a lot of the "files in /tmp security holes" on Unix :)
>
>And one result is that t/op/taint.t can't find a world-writable
>directory and skips several tests...including the one that was
>tripping you up (ignore its message: # all directories writable...
>that's for PCs).

OK, I was assuming sys$scratch would be world-writeable in the sense
that everyone in the world can use the same dir spec to get to
something they can write to, even though they won't be writing to the
same place necessarily.  I don't understand tainting very well so
perhaps that's not what the test is interested in discovering.

Imagine my consternation, though, in finding out that my sys$scratch has
w:rwed access!  Ouch.  That's gonna change right now, and further
enhance my reputation as the one whose job is not to manage the
system but to annoy those who do ;-).

>Looking a bit deeper, it seems that the problem with /sys$scratch
>(as opposed to plain 'sys$scratch') is coming from some VMS-specific
>code in mg.c ... it setting tainting on directories in DCL$PATH, but
>is only parsing "VMS-style" directories.
>
>(as a side note, why is it "tainting" directories with the S_IWUSR
>bit set?  I'd think it would be S_IWOTH...Is it okay for others to
>write into the directory, but not you?)
>
>It may make more sense to have t/op/taint.t "vmsify" directories
>before putting them into DCL$PATH, and the list of directories to
>try shouldn't need changing.

Sounds good, but look what happens when you vmsify /tmp:

$ perl -e "use VMS::Filespec; print vmsify('/tmp');
tmp:[]

Perhaps that's what we want, though, since that will be rejected as a
writeable directory (as long as you don't have a tmp logical) and it
will proceed down the list to /sys$scratch, which vmsify will translate:

$ perl -e "use VMS::Filespec; print vmsify('/sys$scratch');
DISK8:[BERRYC]
____________________________________________
Craig A. Berry                   
mailto:[EMAIL PROTECTED]

Reply via email to