Fixed Running CLI installer/upgrader as root can result in the wrong owner for template files

X

Xon

Well-known member
Affected version
2.1.8
On a linux-like distro; If XenForo (or add-ons) is installed/upgraded via the CLI using root, the wrong file ownership for phrase/templates is trivial to encountered. This can lead to unexpected errors as the operations from the website UI fail because of operations doing on the CLI in a way which can be unexpected.

The very simple solution is if the POSIX functions are included (ie generally included by-default in the php-common or php-process package ); with a user/group combo, root can drop privilege's and ensure files are created by the right user.

It likely requires some new additional configuration items, and probably should make the cmd.php warn-by-default if invoked by root.

I've got the following code in a pile of site's config.php which ensures XF runs as the correct user.
PHP: 
$config['drop_perms']['user'] = "<USER NAME>";
$config['drop_perms']['group'] = "<GROUP NAME>";


if (is_callable('posix_getuid') && posix_getuid() == 0)
{
    if (!empty($config['drop_perms']['group']))
    {
       $name = $config['drop_perms']['group'];
       $groupinfo = posix_getgrnam($name);
       if (empty($groupinfo['gid']))
       {
           throw new \LogicException("Unknown group:".$name);
       }
       posix_setgid($groupinfo['gid']);
    }
    if (!empty($config['drop_perms']['user']))
    {
       $name = $config['drop_perms']['user'];
       $userinfo = posix_getpwnam($name);
       if (empty($userinfo['uid']))
       {
           throw new \LogicException("Unknown user:".$name);
       }
       posix_setuid($userinfo['uid']);
    }
}
 
Might be a good idea to have three modes

  • none (Default)
    Will issue an error if called as root
  • auto
    Will take user & group from internal_data/install-lock.php (if it exists, will error otherwise)
  • manual
    Will take configured user & group
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.0 RC 1).

Change log:
Add a new 'forceCliUser' config option to force commands from the CLI to be executed as a specific user
Click to expand...
There may be a delay before changes are rolled out to the XenForo Community.
 
Just to follow this up with a bit more detail, you'll now be able to specify $config['forceCliUser'] with the name of an account and we'll switch to that user (and their group) when we start the CLI application. If specified and you don't have the necessary POSIX functions, we'll trigger an error; if you run as a different user and you don't have permission to switch to the user (you're not root), we'll trigger an error. If you don't specify a user, nothing changes from onw.

Worth noting that I don't really think that these are inherently bugs. Overall, XF doesn't care about file ownership but about file writability. We've offered chmodWritableValue as a means of forcing this for a long time. We actually already have some code that tries to auto determine the correct value for this based on whether we're running as the same user that did the install lock file. We also had code that forced 0666 when you were running as root, though we did the install lock check; we've just flipped that order now to account for a case where you've done the initial install as root.
 
Back
Top Bottom