#1053 /etc/pagure/pagure.cfg is world readable by default
Closed: Won't Fix a year ago by wombelix. Opened 7 years ago by bruno.

Since the config file contains the secret flask key, I don't think it should be world readable by default. Probably it should be owned by the user that will read it (apache?) and not readable by group or world.


How do you propose we address this? In the sources? In the spec file?

I was thinking the spec file, if ownership by apache or git will work. If multiple accounts need to access the file, then it gets more complicated.
Doing that still has some risks if multiple users can run processes as apache (say by being allowed to run CGI scripts)), but in that case there are probably other ways for them to interfere with Pagure.

This is how it looks on pagure.io:

-rw-r-----. 1 git  postfix 1043 Jun  5  2015 alembic.ini
-rw-r-----. 1 git  postfix 5835 May 28 07:26 pagure.cfg

Thanks.
That isn't good though. The user 'git' will always exist since gitolite is a requirement. But group 'postfix' might not. Also if another mail server is used the group might need to be different.

pagure-milters does require postfix, but if only pagure is installed it doesn't get pulled in and the account might not be there. I need to check if the milters actually read the config file. Presumably they do or it wouldn't be set up that way.

The milter needs to be able to connect to the DB, so it does need to read the file: https://pagure.io/pagure/blob/master/f/milters/comment_email_milter.py#_27-29

That being said, we could always default to git:git 640 and let the admins adjust for their own setup

Would having the milter run as postgis, git instead of postgis, postgis work?

The gitolite user is actually gitolite3, not git in Fedora. RHEL might be different.

So what about just marking it o-rx w/o changing the ownership as this will need to be adjusted by the admins anyway

I think what I should do is try out a config that is close to stock on Fedora or RHEL7 and once it is working make a pull request for the change and people can decide if they like it.

As an aside, it's kind of annoying that the default account for the gitolite3 package isn't 'git'. That ends up making more work or using a more complicated username necessary.

@bruno still interested in trying to fix this issue?

The last update was 5 years ago, no further requests, updates or actionable tasks since then, I'm going to close this issue for now to reduce our backlog.

Metadata Update from @wombelix:
- Issue close_status updated to: Won't Fix
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata