The default bug view has changed. See this FAQ.

queryhelp.cgi ignores group-permissions - showing ALL products

VERIFIED FIXED in Bugzilla 2.16

Status

()

Bugzilla
Query/Bug List
P1
blocker
VERIFIED FIXED
15 years ago
4 years ago

People

(Reporter: Daniel Schwager, Assigned: myk)

Tracking

2.14.1
Bugzilla 2.16
x86
Linux

Details

(Whiteboard: applied to 2.14.2)

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
Hi,

if you login to bugzilla as an user without having permissions (
usebuggroups:on, usebuggroupsentry: on) to show specific products,
all the products AND components are listed on the help-site
http://localhost/bugzilla/queryhelp.cgi 

This is shown also WITHOUT login to the system !!! It is
a security bug !

regards

Danny
-> security group, 2.16 blocker, and reassigning

Oops.
Assignee: barnboy → endico
Group: security?
Severity: major → blocker
Component: Documentation → Query/Bug List
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.16

Comment 2

15 years ago
I disabled http://bugzilla.mozilla.org/queryhelp.cgi by changing the 
permission on the file to be not executable.
Does it matter on b.m.o?  I didn't know you had hidden products.

Comment 4

15 years ago
you're right. we don't. i just renabled it.
ccing netdemon, who wrote this.

Should we remove this file? Its descriptions are out of date given the new query
ui, and it takes ages to load.

Its also really really long and complicated - why should an introductory page
for help on querying give a link to edit products if a user has editcomponents?
It also hard codes values.

If we don't remove it, then the out of date instructions should become a release
blocker (as a separate bug)

Comment 6

15 years ago
I agree that it should be dropped or just be an alternative template for query.cgi.
It is dreadfully slow on our site with over 400 components per product.
Go ahead and drop it for now. I am rewriting the online help system (bug 114179).

Comment 8

15 years ago
I really like having most of that information in one document. The only thing
I dislike is the time it takes to load and the load it puts on the system.

I propose the following changes.

1. Remove the keyword counts. That info isn't particularly useful to
   most users and takes a long time to compute.
2. Change this from a cgi that's run each time each time a user
   looks at it to a script that's run nightly by cron and output to
   a flat html file. Installations with secret products could run it
   by hand when needed and edit out the secret info (or whatever).
Endico: Is that something that would be reliable for all operating systems and
all configurations? What if at the beginning of the day after the first user
entered bugzilla, it spawned a process to do this? It could also do this
manually if there are any changes to the help system.

It would be too bad if this added anymore dependancies to the configuration of
Bugzilla. I did find a perl emulation of cron: http://www.megadodo.demon.co.uk/perl/
This could be spawned possibly after the first user enters the system each days.
Also, remember that not everyone reboots their system or does a shadow database
update each day like b.m.o

With this, I believe, bugzilla could have its own built-in task scheduling
instead of relying on an outside program. 

I hope I'm making sense, because I'm not exactly sure on how cron works or how
the shadow database works :-)

OTOH, I was going to break apart the Bugzilla help system into manageable
sections. Would you rather it be in one file? I think this is something we
should discuss in the newsgroups.

Comment 10

15 years ago
Don't worry about what cron is. You don't need to implement it.
Just make a script that produces a web page (or multiple ones).
Bugzilla administrators can figure out if, when and how to run it.

On the other hand, if there's a better proposal for handling
help, then fine. I kind of like having things in one place, but
that discussion can happen in the news group. In the mean time,
doing what i propose would be a fairly easy fix if we're pressed
for time.
I've started a discussion about the best way to do help in Bugzilla in
n.p.m.webtools. If people could put their thoughts there, that would be great.

Gerv
So, what are we doing for 2.16?
For now, I think we should just remove all the generated lists (products,
keywords, components).

Comment 14

15 years ago
there's no  point in  having this if you're going to remove the generated
lists.
Created attachment 71519 [details]
Possible replacement

Here's a possible replacement help text which I put together, based on Brian's.
If people could review it and tell me if it has the makings of a more helpful
replacement, I'd be grateful :-)

Gerv
Looks good Gervase. Endico: We can throw the generated lists back in when we
restructure the help system. As for the description about the Bugzilla system,
etc that Gervase left out, we can eventually put that back in too. For now,
though, this seems like a good temporary fix so we don't have to rush to get the
help system produced.

Keywords: patch, review
Comment on attachment 71519 [details]
Possible replacement

r=bbaetz, if the w3c validator is happy with it. Are you going to templatise 
it? Its probably not worth it, but it is technically user facing...
Attachment #71519 - Flags: review+
It's an HTML page - it's not dynamic. It is its own template :-)

Gerv
Right - I hadn't noticed that the templatising of *.html got pushed off. Are you
going to redirect the .cgi to the .html? Then redirect back for 2.18? Just chuck
it in a template as is, with a quick wrapper cgi.
I was planning to replace the link on the query page with a link to the HTML
version :-)

Also, it's by no means certain that the 2.18 help will be a separate CGI - see
discussions in the newsgroup.

Gerv
If any part of it is dynamic, it will be a cgi...

I'm mainly concerned about bookmarked links.
> If any part of it is dynamic, it will be a cgi...

Not if it's part of the query page itself. Well, not a separate CGI, anyway.
Please see the NG discussions.

I'> m mainly concerned about bookmarked links.

To the query page help? :-) I'm not convinced that this is a problem.

Gerv

The validator loves it (except for the no-charset thing, but all our pages have
that, right?)

Gerv
What's wrong with just fixing up the CGI?
> What's wrong with just fixing up the CGI?

Well, it is based on the text in the CGI. But the reasons it's very different
are that:

- Doing a CGI thing is more work, if we want the user to see exactly the right
stuff they have permissions for
- Doing the CGI thing is less good - all that dynamic stuff merely confuses. One
user rightly complained to me "All I want to do is search for duplicates. Why do
I have to read 40 pages of 'help' first?" There is an order of magnitude too
much stuff in the old help.

I believe my replacement is the right way to go in the period before we get the
proper help system in place, as outlined in the newsgroup.

Gerv
(Assignee)

Comment 26

15 years ago
Created attachment 77127 [details] [diff] [review]
patch: checks permissions before displaying product

There's no agreement on what to do with the page, so we should do the simple
thing now and figure out the rest after 2.16.  This patch does the same thing
query.cgi does before displaying a product to a user.
reassign to patch author.  Also letting the bot see updates on it.
Assignee: endico → myk
Comment on attachment 77127 [details] [diff] [review]
patch: checks permissions before displaying product

r= justdave
Attachment #77127 - Flags: review+
The only person who has expressed concerns about the new version is MattyT. I
believe I've answered those.

Is anyone actually arguing that (on b.m.o particularly, but generally) the old
version is actually more helpful to any sort of user than the new one?

If no-one wants to stand up and say that, we should check mine in. If someone
wants to make a case for the old one, we can check Myk's in, and argue about it
later.

Gerv
(Assignee)

Comment 30

15 years ago
>Is anyone actually arguing that (on b.m.o particularly, but generally) the old
>version is actually more helpful to any sort of user than the new one?

Yes, Dawn is in comment 8, so let's check in the patch and argue about the file
as a whole later.

Comment 31

15 years ago
i second myk's motion.
Comment on attachment 77127 [details] [diff] [review]
patch: checks permissions before displaying product

<shrug>. OK. r=gerv, then.

Gerv
Attachment #77127 - Flags: review+
*** Bug 130131 has been marked as a duplicate of this bug. ***
Can someone mark the dupe confidential?

Gerv
(Assignee)

Comment 35

15 years ago
Checking in queryhelp.cgi;
/cvsroot/mozilla/webtools/bugzilla/queryhelp.cgi,v  <--  queryhelp.cgi
new revision: 1.9; previous revision: 1.8
done
rlog: /cvsroot/mozilla/webtools/bugzilla/queryhelp.cgi,v:21: missing ';' after
'symbols'
rlog aborted
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
> rlog: /cvsroot/mozilla/webtools/bugzilla/queryhelp.cgi,v:21: missing ';' after
'symbols'
> rlog aborted

Um, what??

bonsai doesn't seem to have picked up the actual diff either, although it was
commited to cvs.
munging ccs
Created attachment 83023 [details] [diff] [review]
Backported patch for BUGZILLA-2_14_1-BRANCH

easy short patch!
Comment on attachment 83023 [details] [diff] [review]
Backported patch for BUGZILLA-2_14_1-BRANCH

2xr=gerv.

Gerv
Attachment #83023 - Flags: review+
Checked in on BUGZILLA-2_14_1-BRANCH.
Whiteboard: applied to 2.14.2
Adding representatives of the packagers to bugs that are going into the
Bugzilla 2.14.2 security update
moving secure bugzilla/webtools bugs from mozilla security group to the new
bugzilla security group.
Group: security? → webtools-security?
2.14.2 is out, removing security group.
Group: webtools-security?
vrfy
Status: RESOLVED → VERIFIED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.