mirror of
https://github.com/Cockatrice/Cockatrice.git
synced 2026-11-05 09:33:25 -08:00
Some checks are pending
CodeQL / Analyze (cpp) (push) Waiting to run
CodeQL / Analyze (actions) (push) Waiting to run
Build Desktop / Configure (push) Waiting to run
Build Desktop / Debian 13 (push) Blocked by required conditions
Build Desktop / Debian 12 (push) Blocked by required conditions
Build Desktop / Fedora 44 (push) Blocked by required conditions
Build Desktop / Fedora 43 (push) Blocked by required conditions
Build Desktop / Servatrice_Debian 12 (push) Blocked by required conditions
Build Desktop / Ubuntu 24.04 (push) Blocked by required conditions
Build Desktop / Ubuntu 26.04 (push) Blocked by required conditions
Build Desktop / Arch (push) Blocked by required conditions
Build Desktop / Ubuntu 26.04 cover (push) Blocked by required conditions
Build Desktop / macOS 13 Intel (push) Blocked by required conditions
Build Desktop / macOS 14 (push) Blocked by required conditions
Build Desktop / macOS 15 (push) Blocked by required conditions
Build Desktop / macOS 26 Debug (push) Blocked by required conditions
Build Desktop / Windows 10 (push) Blocked by required conditions
Build Desktop / Prune caches (push) Waiting to run
Build Docker / Servatrice (arm) (push) Waiting to run
Build Docker / Servatrice (x86) (push) Waiting to run
Build Docker / Publish multi-platform Servatrice image (push) Blocked by required conditions
* [Installer] Stop calling the payload free while an executable is locked The guard answered "nothing is holding the payload" from two lookups that can both miss a running instance: Restart Manager does not reliably report a program's own image or the modules it mapped, and the image path of a process running under another account cannot be read from the probe at all. A user log showed exactly that: the first guard passed while cockatrice.exe was running from the directory, the old uninstaller silently skipped the file it could not delete, and the update aborted half an uninstall later with "cancelled by user" after a close attempt the running window ignored. Ask the file itself. A running image is opened without write sharing, so the write open replacing it needs is refused with ERROR_SHARING_VIOLATION for as long as the program runs, while a file that is merely being read still accepts it. When neither lookup named anybody and a payload executable refuses that open, the probe answers that the file is in use and that the program holding it could not be identified - the guard's "could not confirm" dialog, whose Retry works once the user has closed it - instead of passing the payload as free. Only the payload executables are tested, not every file the purge removes: a locked executable proves a program is running and a mapped DLL belongs to a running executable, while a locked DLL or qt.conf can be the asking process itself, which is the loop the guard already had. The open is retried once after 300 ms, and only for the files that refused, so a scanner holding a file for a moment cannot stop an install for nothing. The Windows probe check now covers that answer: a payload executable held by the asking process, so that it cannot be named, has to come back as in use rather than as free. Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de> * [Installer] Close running clients over a local socket The installer could only ask a running client to close with WM_CLOSE, which an instance hidden in the notification area or sitting on its own confirmation cannot answer usefully. Give every client a per-process local socket and have the holder probe ask it there first, falling back to WM_CLOSE for clients from before the socket. * [Installer] Offer to check again or update by hand when files stay locked Replace the two-answer guard prompt with force close, close by hand and check again, or cancel. Retry the automatic close while the set of holders changes, and point a cancelled run at the latest release so a user who does not want anything killed has a way forward that is not cancelling the update again. --------- Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
51 lines
2.2 KiB
C++
51 lines
2.2 KiB
C++
#ifndef PAYLOAD_PATHS_H
|
|
#define PAYLOAD_PATHS_H
|
|
|
|
#include <string>
|
|
|
|
/**
|
|
* @brief The file names of the programs the payload installs, in the order the guard names
|
|
* them.
|
|
*
|
|
* The single list behind isPayloadProgram(), so the guard acts on exactly the programs it
|
|
* names, and so a payload program added later is closed, ended and tested for a lock
|
|
* without a second list to update. A payload executable that refuses to be written is
|
|
* running, which is what makes this list the evidence the two process lookups cannot
|
|
* provide - see payloadExecutablesInUse().
|
|
*/
|
|
inline constexpr const wchar_t *PAYLOAD_PROGRAMS[] = {L"cockatrice.exe", L"oracle.exe", L"servatrice.exe"};
|
|
|
|
/**
|
|
* @brief The last name in @p path: what follows its last separator, or @p path itself when
|
|
* it has none.
|
|
*
|
|
* Empty for an empty path and for one that ends in a separator, which has no name of its
|
|
* own - a caller that hands in a directory there gets no name rather than the directory's
|
|
* own last component.
|
|
*/
|
|
std::wstring fileNameOf(const std::wstring &path);
|
|
|
|
/**
|
|
* @brief The directory @p path lies in, without a trailing separator.
|
|
*
|
|
* Empty when @p path has no directory part. Used to tell where a process was started from:
|
|
* an image running directly in the install directory has that directory as its parent,
|
|
* while one started from a folder below it has that folder, and the two are not the same
|
|
* answer to "does this process belong to the installation being replaced?".
|
|
*/
|
|
std::wstring parentDirectoryOf(const std::wstring &path);
|
|
|
|
/**
|
|
* @brief Whether @p imageName is one of the programs the payload installs.
|
|
*
|
|
* The single place that answers which images are Cockatrice's own, so the guard acts on the
|
|
* same set it names, and so a program a user happens to keep in the install directory is
|
|
* never treated as an instance of the application. Matched on the image name alone, without
|
|
* case: the names are the payload's own, and the comparison is deliberately free of Windows
|
|
* API so it can be exercised off Windows.
|
|
*
|
|
* @param imageName the file name of a process image, empty when it could not be read
|
|
*/
|
|
bool isPayloadProgram(const std::wstring &imageName);
|
|
|
|
#endif
|