1284336 - Sensible group should be used as the webservergroup only if the user is a member of that group

Status: NEW

(Bugzilla :: Bugzilla-General, defect)

Description

[Dylan Hardison [:dylan] (he/him)]

This is far more likely to be correct with plack-based setups.

Comment 1

[GitHub Autolander Bot]

Attachment: [bugzilla] dylanwh:bug-1284336 > bugzilla:master

Comment 2

[Frédéric Buclin]

Comment on attachment 8767763 [details] [review]
[bugzilla] dylanwh:bug-1284336 > bugzilla:master

I don't know which problem you try to solve, but on my machine, it would return "root" instead of "apache". This is not acceptable.

Comment 3

[Dylan Hardison [:dylan] (he/him)]

(In reply to Frédéric Buclin from comment #2)
> Comment on attachment 8767763 [details] [review]
> [bugzilla] dylanwh:bug-1284336 > bugzilla:master
> 
> I don't know which problem you try to solve, but on my machine,

Reduce common frustrations with getting a new bugzilla setup. 

> it would
> return "root" instead of "apache". This is not acceptable.

Your effective group id is root? I suppose if you're running checksetup as root... actually,
when you're running as root it is sensible to use the value of $sensible_group and if non-root something else. I'll go with that approach.

Comment 4

[Frédéric Buclin]

(In reply to Dylan Hardison [:dylan] from comment #3)
> Reduce common frustrations with getting a new bugzilla setup. 

"common" frustration?? I think "apache" is way more common than some random group name.


> when you're running as root it is sensible to use the value of
> $sensible_group and if non-root something else. I'll go with that approach.

This wouldn't fix my case: on the GCC server, I'm not logged in as root and the value returned by getgrgid($EGID) is totally unusable.

Comment 5

[Dylan Hardison [:dylan] (he/him)]

Comment on attachment 8767763 [details] [review]
[bugzilla] dylanwh:bug-1284336 > bugzilla:master

Different approach -- won't set webservergroup to $EGID if $EUID is root.

The rationale for this is that there is often an 'apache' or '_www' group that the user running checksetup is not a member of. 

When bugzilla is running under plack as either fastcgi or starman/thrall/etc, the most likely situation is that there is a specific user and group for it.

Comment 6

[Dylan Hardison [:dylan] (he/him)]

(In reply to Frédéric Buclin from comment #4)
> This wouldn't fix my case: on the GCC server, I'm not logged in as root and
> the value returned by getgrgid($EGID) is totally unusable.

Interesting! What perl version and OS is that? I'll make a second revision once I figure out why that's the case.

Comment 7

[Dave Miller [:justdave]]

Your average Joe User trying out Bugzilla is probably going to be on shared hosting, and using the user's own group is almost always going to be appropriate, if they're not root when they run it.  When you run it as root, do what we used to do.

Sounds like that's where this is going now, you guys got several more comments in while I was typing that because I was distracted. :)

Comment 8

[Frédéric Buclin]

(In reply to Dylan Hardison [:dylan] from comment #6)
> Interesting! What perl version and OS is that? I'll make a second revision
> once I figure out why that's the case.

This has nothing to do with perl or the OS. It has to do with the fact that I'm in several groups, and apache is not the primary group.

Comment 9

[Dylan Hardison [:dylan] (he/him)]

but root is the primary group? that's sort of weird.

However this patch really doesn't accomplish what I want anyway. The right solution is to make sure that the user running checksetup (for the first time) can chgrp files into $sensible_group -- e.g. we should check that the user is a member of that group. If not, then use whichever group is the effective one (which should be the primary group unless the user has used newgrp().

Comment 10

[Frédéric Buclin]

(In reply to Dylan Hardison [:dylan] from comment #9)
> but root is the primary group? that's sort of weird.

No, I'm root on my local machine. On the GCC server (a production server), I'm not root, but I am in several groups to be allowed to access different parts of the server.

Comment 11

[Firefox Bug Husbandry Bot]

Removing good-first-bug keyword because team does not have bandwidth to mentor at the moment.

Comment 12

[Firefox Bug Husbandry Bot]

Removing outreachy because team does not have bandwidth to mentor this cycle.