Permissions setup option for bugzilla_user==webserver_user (suexec)

RESOLVED FIXED in Bugzilla 3.6

Status

()

Bugzilla
Installation & Upgrading
P2
enhancement
RESOLVED FIXED
16 years ago
8 years ago

People

(Reporter: Andreas Franke (gone), Assigned: Wurblzap)

Tracking

2.15
Bugzilla 3.6
Dependency tree / graph
Bug Flags:
approval +

Details

Attachments

(1 attachment, 3 obsolete attachments)

5.73 KB, patch
Max Kanat-Alexander
: review+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
Bugzilla already allows for the following situations:
A) bugzilla and apache are different users, and they are not in the same group
   -> several important directories are made world writable
B) bugzilla and apache are different users, but they are in the same group
   -> several important directories are made group writable

In our installation, we have the following case:
C) bugzilla and apache are the same user.
   -> everything should be writable only by the user;
      no write permissions for group or others are necessary

For some reason, I really needed to hack bugzilla to do this: Sometimes, on our
(NFS-shared) file systems files writable by the group "nobody" are mysteriously
deleted, and our sysadmin hasn't found the responsible process or user yet.

Since the data directory was affected, this caused the params file to disapper,
among others (collected stats, .htaccess files, ...). The missing params file
caused all sorts of badness, most noticeably: Bugzilla displayed the mozilla
banner instead of our own, all products were suddenly visible to everybody
(since use*groups was suddently off), and the QA contact field was missing. 

After I changed permission settings from 777 or 775 to 755 and permission
settings from 666 or 664 to 644, this problem did not occur any more.
Thus I'm now filing this bug to make this an "officially supported" installation
option. Or are there any problems with this?
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18

Comment 1

14 years ago
These unloved bugs have been sitting untouched since June 2002 or longer.  If
nobody does anything else to them, they certainly won't make 2.18
Retargetting to 2.20.  If you really plan to push them right now, you might pull
them back in.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20

Updated

13 years ago
Severity: normal → enhancement
OS: Linux → All
Hardware: PC → All

Comment 2

13 years ago
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 nobody@bugzilla.org 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.
Target Milestone: Bugzilla 2.20 → ---
any relation to running it under suexec?  see also bug 105366, not sure if this
is quite a dupe though.

Updated

12 years ago
QA Contact: mattyt-bugzilla → default-qa
Let's make this not a dupe.  The other bug is about docs, this one can be able making Bugzilla actually deal with it correctly.  There's a fair number of people trying to run Bugzilla under suexec nowadays, mostly because of the proliferation of cheap shared hosting, so we should go ahead and make checksetup.pl set things up correctly for that situation.

See bug 105366 comment 25 for the basics, but I bet the list of files that need to be readable is different.  See also comment 1 on this bug -- with apache running as that user, it should be possible to lock down data files to be accessible only by the owner.  Any files that need to be accessed by the webserver that aren't executable need to be able to be read by the webserver (which won't necessarily be the same user) however.
Target Milestone: --- → Bugzilla 3.2
(Assignee)

Comment 5

10 years ago
Created attachment 276748 [details] [diff] [review]
Patch

Work in progress.
Assignee: zach → wurblzap
Status: NEW → ASSIGNED
(Assignee)

Comment 6

10 years ago
Comment on attachment 276748 [details] [diff] [review]
Patch

This appears to work nicely!
Attachment #276748 - Flags: review?(mkanat)
Attachment #276748 - Flags: review?(justdave)

Comment 7

10 years ago
Comment on attachment 276748 [details] [diff] [review]
Patch

I would prefer just a boolean, "$suexec", unless there's some good reason to have a whole separate group that just obsoletes the webservergroup.

But generally this looks good.
Attachment #276748 - Flags: review?(mkanat)
Attachment #276748 - Flags: review?(justdave)
Attachment #276748 - Flags: review-
(Assignee)

Comment 8

10 years ago
Created attachment 276925 [details] [diff] [review]
Patch 2

Ok... This makes this way more complicated because the webservergroup localconfig parameter needs to be morphed, but here we go.
Attachment #276748 - Attachment is obsolete: true
Attachment #276925 - Flags: review?(mkanat)

Comment 9

10 years ago
Comment on attachment 276925 [details] [diff] [review]
Patch 2

Don't change the name of the parameter. It's still, really, the group the web server is accessing the files as (though it may not be the group the server is running as). You can just adjust the comment, and explain more in $use_suexec.
Attachment #276925 - Flags: review?(mkanat) → review-
(Assignee)

Comment 10

10 years ago
Comment on attachment 276925 [details] [diff] [review]
Patch 2

(In reply to comment #9)
> Don't change the name of the parameter. It's still, really, the group the web
> server is accessing the files as (though it may not be the group the server is
> running as). You can just adjust the comment, and explain more in $use_suexec.

No, it's not as simple as this. The web server is accessing non-executable files using its own permissions, and executing executable files using the SuexecUserGroup.

Plus, I don't like keeping outdated explanations (localconfig comments) in existing installations. Modifying the comment doesn't update existing localconfig files. The flavour of the parameter changes enough to warrant a visible change.
Attachment #276925 - Flags: review?(mkanat)

Comment 11

10 years ago
It doesn't seem like testserver will be able to figure out that you are actually running the webserver suexec.  You need to find a way to deal with this sensibly.  Currently, it checks the group setting of the webserver processes.  In the suexec case, the webserver processes will not take on the suexec users' userid until later.

Comment 12

10 years ago
(In reply to comment #10)
> No, it's not as simple as this. The web server is accessing non-executable
> files using its own permissions, and executing executable files using the
> SuexecUserGroup.

  So do we use two groups, or one?

> Plus, I don't like keeping outdated explanations (localconfig comments) in
> existing installations.

  Then you should fix bug 147776, and not try to work around it in some way.

  Unless two groups are needed, don't change the name of the parameter. If two groups are needed, then my first review was incorrect.
(Assignee)

Comment 13

10 years ago
(In reply to comment #11)
The patch (over?)simplifies this a little by saying the group is all right if
$use_suexec is set (that's the $webgroupnum == $sgid ||
Bugzilla->localconfig->{use_suexec} part of the patch).

(In reply to comment #12)
>   So do we use two groups, or one?

This could be solved using two groups, of course. This patch uses one. The reason is that then non-root users (who suffer most from Bugzilla not supporting SuexecUserGroup neatly) don't need to chown to a group they don't belong to. Instead, checksetup.pl opens static files (.js, .css and so on) to be world-readable.

>   Then you should fix bug 147776, and not try to work around it in some way.

This bug is not about fixing bug 147776, and bug 147776 will not be fixed here. Unless we set up a blocking relationship, it *needs* to be worked around.

>   Unless two groups are needed, don't change the name of the parameter. If two

I'm not clinging to changing the parameter's name. In fact, I don't like changing it much either. It's the reason the first patch introduced a second group name. If you have a better workaround to bug 147776, I'm fine with keeping the name.
I think we'd be better off making the static files world-readable, and sticking with the single webservergroup (and telling people in the docs to use their own group if they're in a shared-hosting environment).

Comment 15

10 years ago
I suppose we ought to fix bug 147776 first, then.
Depends on: 147776

Comment 16

10 years ago
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
(Assignee)

Comment 17

10 years ago
Comment on attachment 276925 [details] [diff] [review]
Patch 2

Retracting review request until the new dependency is resolved.
Attachment #276925 - Flags: review?(mkanat)
(Assignee)

Updated

10 years ago
Duplicate of this bug: 399972

Updated

10 years ago
Summary: Permissions setup option for bugzilla_user==webserver_user → Permissions setup option for bugzilla_user==webserver_user (suexec)
showdependancygraph also needs to chmod its files so that the webserver can read it.

Updated

9 years ago
Blocks: 457373

Comment 20

9 years ago
Okay, now that the blocker is fixed, we don't need to rename the variable. Wurblzap, will you have time some time soon to write a new patch, or should I work on revising it myself?
Priority: P3 → P2
(Assignee)

Comment 21

9 years ago
Created attachment 364894 [details] [diff] [review]
Patch 3

All right, now that bug 147776 has landed, this is a breeze.
Attachment #276925 - Attachment is obsolete: true
Attachment #364894 - Flags: review?(mkanat)
(Assignee)

Updated

9 years ago
Target Milestone: Bugzilla 4.0 → Bugzilla 3.4

Updated

9 years ago
Target Milestone: Bugzilla 3.4 → Bugzilla 3.6

Comment 22

9 years ago
Comment on attachment 364894 [details] [diff] [review]
Patch 3

>-        desc    => q{# This is the group your web server runs as.
>+        desc    => q{# This is the group the Bugzilla scripts are being run as.

  I'd leave that line as it is, I think it's clearer for the default case.

>+# If you have use_suexec switched off below, this is the group your web server
>+# runs as. If you have it switched on, this is the group Apache switches to
>+# in order to run Bugzilla scripts.

  I'd just leave the "If you have use_suexec switched on" line.


>+# Set this if Bugzilla runs in an Apache SuexecUserGroup environment.

  Note here in parentheses that if your web server runs control panel software like cPanel or Plesk, or if you are on shared hosting, then you are almost certainly running under suexec (most people in these situations are unaware of their own Apache configuration).


>+# If you have a Windows box, ignore this setting.
>+# If set to 0, Bugzilla will set file permissions as tightly as possible.
>+# If set to 1, Bugzilla will set file permissions so that it may work in an
>+# SuexecUserGroup environment. The difference is that static files will
>+# receive world read permissions.

  "static files (like CSS, JavaScript, etc.)"

  I still have to test this, but it really does look right, and very simple now, which is awesome. :-)
Attachment #364894 - Flags: review?(mkanat) → review+

Comment 23

9 years ago
Holding approval until we branch (which should be pretty soon, we were thinking of doing it along with the 3.3.4 release).
Flags: approval?

Updated

9 years ago
Keywords: relnote

Comment 24

9 years ago
Oh, also, we should revert or modify the docs checked in as part of bug 105366 for HEAD along with this checkin. Wurblzap, do you want to post a patch here for that?
(Assignee)

Comment 25

9 years ago
Created attachment 364915 [details] [diff] [review]
Patch 3.0.1

Tweaked wording of comments.
Attachment #364894 - Attachment is obsolete: true
Attachment #364915 - Flags: review?(mkanat)

Updated

9 years ago
Attachment #364915 - Flags: review?(mkanat) → review+

Comment 26

9 years ago
Comment on attachment 364915 [details] [diff] [review]
Patch 3.0.1

Looks great. :-)
Comment on attachment 364915 [details] [diff] [review]
Patch 3.0.1

Does this work for the graph stuff? Theres the chmod logic in the cgi for that, too, that has to be dealt with.

(I'm way way too swamped to look at this this week)

Updated

9 years ago
Flags: approval? → approval+
(Assignee)

Comment 28

9 years ago
Checking in testserver.pl;
/cvsroot/mozilla/webtools/bugzilla/testserver.pl,v  <--  testserver.pl
new revision: 1.21; previous revision: 1.20
done
Checking in Bugzilla/Install/Filesystem.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v  <--  Filesystem.pm
new revision: 1.35; previous revision: 1.34
done
Checking in Bugzilla/Install/Localconfig.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Localconfig.pm,v  <--  Localconfig.pm
new revision: 1.17; previous revision: 1.16
done
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 29

8 years ago
Added to the release notes in bug 547466.
Keywords: relnote

Updated

8 years ago
Blocks: 561797
You need to log in before you can comment on or make changes to this bug.