Description of problem:
/etc/abrt/plugins/RHTSupport.conf should be readable only by it's owner because it may contain password to GSS portal. (It's done this way for Bugzilla.conf.)
Similar for following conf files:
newman@dhcp-lab-222 ~ $ sudo grep -i pass -n /etc/abrt/plugins/*
/etc/abrt/plugins/Bugzilla.conf:9:# your password
/etc/abrt/plugins/FileTransfer.conf:23:# for example: ftp://user:firstname.lastname@example.org/directory
/etc/abrt/plugins/FileTransfer.conf:24:# or: scp://user:email@example.com:port/directory etc.
/etc/abrt/plugins/ReportUploader.conf:12:# for example: ftp://user:firstname.lastname@example.org/directory
/etc/abrt/plugins/ReportUploader.conf:13:# or: scp://user:email@example.com:port/directory etc.
/etc/abrt/plugins/RHTSupport.conf:8:# Your password
/etc/abrt/plugins/RHTSupport.conf:9:Password = redhat
Version-Release number of selected component (if applicable):
I don't agree with this, actually even Bugzilla.conf should be readable, as the settings from that file are meant to be used as "defaults" and are passed to the clients (gui/cli) anyway, so making it not readable doesn't make sense...
Why would anyone put password to world-readable file? GUI and CLI may ask daemon for the defaults.
(In reply to comment #2)
> GUI and CLI may ask daemon for the defaults.
Yes, that's what happen, daemon tells the password to gui/cli which means it's passed to the non-root app, so what's the point of making it not-readable, when user can read it in gui/cli anyway? These files are not meant to be used for secrets, they just *can be* if root want's to set the password somewhere save he can use $HOME/.abrt/<plugin_name>.conf, but imagine a situation where you want all user to use the same account for submitting a bugs ...
I asked the DOC guys to mention this "feature" in the deployment guide:
and closing this as NOTABUG.