@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

When already running as the daemon user, don't "sudo" daemon commands

Summary:
The cluster synchronization code runs either actively (before returning a response to `git clone`, for example) or passively (routinely, as the daemons update reposiories).

The active sync runs as the web user (if running `git clone http://...`) or the VCS user (if running `git clone ssh://...`). But the passive sync runs as the daemon user.

All of these sync processes need to run actual commands as the daemon user (`git fetch ...`).

For the active ones, we must `sudo`.

For the passive ones, we're already the right user. We run the same code, and end up trying to sudo to ourselves, which `sudo` isn't happy about by default.

Depending on how `sudo` is configured and which users things are running as this might work anyway, but it's silly and if it doesn't work it requires you to go make non-obvious, weird config changes that are unintuitive and somewhat nonsensical. This is probably worse on the balance than adding a bit of complexity to the code.

Instead, test which user we're running as. If it's already the right user, don't sudo.

Test Plan:
- Ran `bin/repository update --trace` as daemon user, saw no more `sudo`.
- Ran a `git clone` to make sure that didn't break.

Reviewers: chad, avivey

Reviewed By: avivey

Differential Revision: https://secure.phabricator.com/D16391

+18
+18
src/infrastructure/daemon/PhabricatorDaemon.php
··· 34 34 return $command; 35 35 } 36 36 37 + // We may reach this method while already running as the daemon user: for 38 + // example, active and passive synchronization of clustered repositories 39 + // run the same commands through the same code, but as different users. 40 + 41 + // By default, `sudo` won't let you sudo to yourself, so we can get into 42 + // trouble if we're already running as the daemon user unless the host has 43 + // been configured to let the daemon user run commands as itself. 44 + 45 + // Since this is silly and more complicated than doing this check, don't 46 + // use `sudo` if we're already running as the correct user. 47 + if (function_exists('posix_getuid')) { 48 + $uid = posix_getuid(); 49 + $info = posix_getpwuid($uid); 50 + if ($info && $info['name'] == $user) { 51 + return $command; 52 + } 53 + } 54 + 37 55 // Get the absolute path so we're safe against the caller wiping out 38 56 // PATH. 39 57 $sudo = Filesystem::resolveBinary('sudo');