190188 - checksetup.pl doesn't check file permissions before open(), nor does it check the return value of open()

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect)

Description

[Jonathan Schatz]

User-Agent:       Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203
Build Identifier: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203

After i updated my cvs tree to HEAD, i noticed checksetup.pl was broken. i got
several "print to closed filehandle" errors. i found the errors and corrected
them. i'll attach a patch after i submit this bug.

Reproducible: Always

Steps to Reproduce:
1.chmod localconfig 444
2. ./checksetup.pl


Actual Results:  
perl errors ("print on closed filehandle at ./checksetup.pl, line 385). 

Expected Results:  
not spit out errors.

Comment 1

[Jonathan Schatz]

Attachment: patch to fix broken use of open() at line 385

Comment 2

[Dave Miller [:justdave]]

-> patch author

Comment 3

[Zach Lipton [:zach]]

Comment on attachment 112333 [details]
patch to fix broken use of open() at line 385

>-    open FILE, '>>localconfig';
>+    if (-e 'localconfig' and not -W 'localconfig') {
>+       chmod('0644','localconfig');
>+    }
>+    open FILE, '>>localconfig' or die "Couldn't write to localconfig: $!";

I'm not so crazy about chmoding localconfig as 644 (according to a landfill
install, it's 640 by default). It seems likely to introduce a security hole
down the line if there is a bug in the chmod'ing section of checksetup. How
about we just add the die statement to open (I should add a test to check for
die calls on all calls to open) and include something in the error message to
the effect that it would be a good idea to ensure that the user running
checksetup can write to localconfig.

Comment 4

[Joel Peshkin]

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.

Comment 5

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 6

[Jonathan Schatz]

sorry, didn't realize this was assigned to me. my bugzilla.vmware.com tree
hasn't been sync'd since 2.17.4, so i'm not the right person to work on this.

Comment 7

[Max Kanat-Alexander]

I've fixed all these instances as part of the various blockers to the "reorganize checksetup" bug.

Comment 8

[Max Kanat-Alexander]

*** Bug 122110 has been marked as a duplicate of this bug. ***