[request-tracker-maintainers] Bug#676322: Bug#676322: request-tracker4: rt-crontool permissions not as recommended

[Dominic Hargreaves]

severity 676322 wishlist
retitle 676322 Provide a general purpose 'rt' group for non-web utilities to run under
thanks

On Wed, Jun 06, 2012 at 09:04:46AM +0200, Torben Nehmer wrote:
> rt-crontool is not useable with users outside of user root (not recommended) and group www-data. The 
> documentation of RT-Crontool specifies:
> 
> ---
> This tool allows the user to run arbitrary perl modules from within RT. If this tool were setgid, a hostile 
> local user could use this tool to gain administrative access to RT. It is incredibly important that 
> nonprivileged users not be allowed to run this tool. It is suggested that you create a non-privileged unix user 
> with the correct group membership and RT access to run this tool (see User Configuration below).
> 
> [...]
> 
> rt-crontool should ideally be run by a special unprivileged operating system user who has also been entered in 
> RT as a privileged user with global [= ModifyTicket ] and [= ShowTicket ] rights. If you have created an 
> operating system user named rtcrontool, for instance, then create an RT user with Username and Unix login set to 
> rtcrontool, check Let this user be granted rights, and assign a password. Then under Configuration/Global/User 
> rights, add the two rights to the user you just created. This user should have read access to the RT files such 
> as RT_Config.pm and RT_SiteConfig.pm. If, for example, the rt group has read access to all the installed RT 
> files, you should assign your created user to that group (under UNIXen).
> 
> http://requesttracker.wikia.com/wiki/UseRtCrontool
> ---
> 
> It also seems, that runnint rt-crontool as root is inappropriate ("Somebody indicates that you can run the tool 
> as root (uid 0), but that didn't work properly for me when using rt-crontool to do priority escalation.").
> 
> In addition, simply using a unprivilged system account requires that account to be in the group www-data, which 
> is doable, but not necessarily nice as the RT_SiteConfig.pm file's permissions prevent access from other users:
> 
> -rw-r----- 1 root www-data 12405 29. Mär 17:09 RT_SiteConfig.pm
> 
> If I read the aforementioned Wiki page right, the default way would be having RT have its own system group 
> which owns the files in question. That again would need Apache to be in that system group, so I am not sure what
> the ideal solution here is as both Apache and rt-crontool need access to the configuration files.
> 
> However, adding rt-crontool users to www-data definitly is a workaround to with.

I think this pretty site dependent. The permissions of the config file
are under the system administrator's control, so you are free to
implement whatever you think is appropriate. There are also database
local user ACLs to think about (for SQLite and PostgreSQL ident auth,
at least).

That said, creating an 'rt' group and adding www-data to it for new
installs might not be a bad idea, but it's definitely low-priority for
me at the moment.

Retitling and downgrading, since the sysadmin is free to change the
permissions to suit site-specific requirements; no change in the
package is strictly required.

Thanks,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)