Checksetup leaves editor backups of localconfig accessible

RESOLVED FIXED in Bugzilla 2.18

Status

()

defect
P1
blocker
RESOLVED FIXED
17 years ago
2 months ago

People

(Reporter: bugreport, Assigned: bugreport)

Tracking

2.17.1
Bugzilla 2.18
Bug Flags:
approval +

Details

(Whiteboard: [fixed on trunk][fixed in 2.14.5][fixed in 2.16.2])

Attachments

(3 attachments, 7 obsolete attachments)

Any user who uses vim will have files such as localconfig~ which are left
accessible.
I just fixed this for bugzilla-stable on landfill...

We _so_ need to move all of this stuff out of the webtree, but I don't think we
have the infrastructure yet for that.
Posted patch Patch for new sites (obsolete) — Splinter Review
This is a change to checksetup that causes it to write the right .htaccess file
in the first place

The problem, however, is that checksetup will only create the file if it
doesn't already exist.
Actually, this should be done as a checksetup issue...
Assignee: justdave → zach
Component: Bugzilla-General → Installation & Upgrading
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.18
Posted patch Patch including repair code (obsolete) — Splinter Review
OK, this patch changes the .htaccess file from 
localconfig|nextfile
to
localconfig.*|nextfile
Which will work for anyone who let checksetup build .htaccess for them and runs
checksetup again.
Attachment #109889 - Attachment is obsolete: true
Posted patch Same patch for 2_16 (obsolete) — Splinter Review
Posted patch Same patch for 2_14 (obsolete) — Splinter Review
It's a good thing I'm such a slacker and we haven't released yet... ;-)

Are we gonna fold this fix into the security announcement for 2.14.x/2.16.x, and
the three releases due out this weekend (2.14.5 and 2.16.2 and 2.17.2)? Justdave?

Bueller?

Bueller?
yes, we'll hold release for this.
Attachment #109897 - Flags: review+
Attachment #109899 - Flags: review+
Attachment #109900 - Flags: review+
make it so
Assignee: zach → bugreport
Flags: approval+
Whiteboard: [wanted for trunk][wanted for 2.14.5][wanted for 2.16.2]
On HEAD:
 Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.212; previous revision: 1.211
done 

On BUGZILLA-2_14_1-BRANCH:
Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.99.2.2; previous revision: 1.99.2.1
done                                                      

On BUGZILLA-2_16-BRANCH :
Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.149.2.12; previous revision: 1.149.2.11
done                

                                     
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
OS: other → All
Hardware: PC → All
Whiteboard: [wanted for trunk][wanted for 2.14.5][wanted for 2.16.2] → [fixed on trunk][fixed in 2.14.5][fixed in 2.16.2]
Posted patch Further patch for 2.14 (obsolete) — Splinter Review
OOPS forgot about localconfig.js must be accessable
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Posted patch Further patch for 2.14 (obsolete) — Splinter Review
Note that some editors use "~localconfig" or "#localconfig" or other schemes.

Surely it's the responsibility of an admin to configure their editor not to
leave backups of sensitive files lying around? :-)

Are we going to have to rename localconfig.js to make this work, or can we add
an exception for it?

Gerv
Ok... so are (yet again) holding the release for this?

There's a reason I put "released this weekend" in the status report... I wanted
to give us the flexibility for stuff like this. :-)
This patch requires backing out the old patch first

This uses .*localconfig.*
but then countermands that in a subsequent block with an allow from all
Attachment #109929 - Attachment is obsolete: true
Attachment #109930 - Attachment is obsolete: true
Attachment #109931 - Attachment is obsolete: true
Ok... just talked to joel on IRC, and I guess the checked in patch isn't good
enough; when this bug is closed again, with the proper fix checked in on all the
branches, I'll go ahead and retag all the releases, which I have to do anyway
because we forgot relnotes for 2.14.5 and 2.16.2.
Comment on attachment 109937 [details] [diff] [review]
Replacement patch for TIP

Tested on landfill w/ 2.17.2; looks good.

r=preed
Attachment #109937 - Flags: review+
Same for 2.16 
Back out prior patch first
Attachment #109897 - Attachment is obsolete: true
Attachment #109899 - Attachment is obsolete: true
Attachment #109900 - Attachment is obsolete: true
Same story, back out prior patch first
Comment on attachment 109938 [details] [diff] [review]
Replacement patch for 2_16

TIP version works ok, TIP/2.16/2.14 look ok and apply ok.

r=burnus

(Hopefully not to many have already run ./checksetup from tip, otherwise
localconfig.js is unavailable. Maybe
+    if ($oldaccess =~ s/\|localconfig\|/\|.*localconfig.*\|/) {
should be changed to
+    if ($oldaccess =~ s/\|localconfig(\.\|)?\|/\|.*localconfig.*\|/) {
At least I have run already the wrong update.)
Attachment #109938 - Flags: review+
Attachment #109939 - Flags: review+
Comment on attachment 109937 [details] [diff] [review]
Replacement patch for TIP

Note that this patch will add the FilesMatch for allowing the .js and .rdf at
the end of the .htaccess file...  if a site is blocking IPs because of robots
or DOSes (like mothra), this will put the new check after those, thus allowing
the banned IPs to still access those files (because an "allow from all" was the
last match).  Probably doesn't matter a whole lot.  People who are maintaining
that type of thing can fix it themselves. :-)
Fixed in all 3 branches (again)
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Public notice complete. Removing security flag.
Group: webtools-security
lack of responce
lack of response to what?  it's already fixed.
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.