Revision 7b70e9efb18c2cc3f219af399bd384c5801ba1d7 authored by Jeff King on 16 April 2024, 08:35:33 UTC, committed by Johannes Schindelin on 17 April 2024, 20:29:56 UTC
The upload-pack command tries to avoid trusting the repository in which it's run (e.g., by not running any hooks and not using any config that contains arbitrary commands). But if the server side of a fetch or a clone is a partial clone, then either upload-pack or its child pack-objects may run a lazy "git fetch" under the hood. And it is very easy to convince fetch to run arbitrary commands. The "server" side can be a local repository owned by someone else, who would be able to configure commands that are run during a clone with the current user's permissions. This issue has been designated CVE-2024-32004. The fix in this commit's parent helps in this scenario, as well as in related scenarios using SSH to clone, where the untrusted .git directory is owned by a different user id. But if you received one as a zip file, on a USB stick, etc, it may be owned by your user but still untrusted. This has been designated CVE-2024-32465. To mitigate the issue more completely, let's disable lazy fetching entirely during `upload-pack`. While fetching from a partial repository should be relatively rare, it is certainly not an unreasonable workflow. And thus we need to provide an escape hatch. This commit works by respecting a GIT_NO_LAZY_FETCH environment variable (to skip the lazy-fetch), and setting it in upload-pack, but only when the user has not already done so (which gives us the escape hatch). The name of the variable is specifically chosen to match what has already been added in 'master' via e6d5479e7a (git: extend --no-lazy-fetch to work across subprocesses, 2024-02-27). Since we're building this fix as a backport for older versions, we could cherry-pick that patch and its earlier steps. However, we don't really need the niceties (like a "--no-lazy-fetch" option) that it offers. By using the same name, everything should just work when the two are eventually merged, but here are a few notes: - the blocking of the fetch in e6d5479e7a is incomplete! It sets fetch_if_missing to 0 when we setup the repository variable, but that isn't enough. pack-objects in particular will call prefetch_to_pack() even if that variable is 0. This patch by contrast checks the environment variable at the lowest level before we call the lazy fetch, where we can be sure to catch all code paths. Possibly the setting of fetch_if_missing from e6d5479e7a can be reverted, but it may be useful to have. For example, some code may want to use that flag to change behavior before it gets to the point of trying to start the fetch. At any rate, that's all outside the scope of this patch. - there's documentation for GIT_NO_LAZY_FETCH in e6d5479e7a. We can live without that here, because for the most part the user shouldn't need to set it themselves. The exception is if they do want to override upload-pack's default, and that requires a separate documentation section (which is added here) - it would be nice to use the NO_LAZY_FETCH_ENVIRONMENT macro added by e6d5479e7a, but those definitions have moved from cache.h to environment.h between 2.39.3 and master. I just used the raw string literals, and we can replace them with the macro once this topic is merged to master. At least with respect to CVE-2024-32004, this does render this commit's parent commit somewhat redundant. However, it is worth retaining that commit as defense in depth, and because it may help other issues (e.g., symlink/hardlink TOCTOU races, where zip files are not really an interesting attack vector). The tests in t0411 still pass, but now we have _two_ mechanisms ensuring that the evil command is not run. Let's beef up the existing ones to check that they failed for the expected reason, that we refused to run upload-pack at all with an alternate user id. And add two new ones for the same-user case that both the restriction and its escape hatch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
1 parent f4aa8c8
tempfile.h
#ifndef TEMPFILE_H
#define TEMPFILE_H
#include "list.h"
#include "strbuf.h"
/*
* Handle temporary files.
*
* The tempfile API allows temporary files to be created, deleted, and
* atomically renamed. Temporary files that are still active when the
* program ends are cleaned up automatically. Lockfiles (see
* "lockfile.h") are built on top of this API.
*
*
* Calling sequence
* ----------------
*
* The caller:
*
* * Attempts to create a temporary file by calling
* `create_tempfile()`. The resources used for the temporary file are
* managed by the tempfile API.
*
* * Writes new content to the file by either:
*
* * writing to the `tempfile->fd` file descriptor
*
* * calling `fdopen_tempfile()` to get a `FILE` pointer for the
* open file and writing to the file using stdio.
*
* Note that the file descriptor created by create_tempfile()
* is marked O_CLOEXEC, so the new contents must be written by
* the current process, not any spawned one.
*
* When finished writing, the caller can:
*
* * Close the file descriptor and remove the temporary file by
* calling `delete_tempfile()`.
*
* * Close the temporary file and rename it atomically to a specified
* filename by calling `rename_tempfile()`. This relinquishes
* control of the file.
*
* * Close the file descriptor without removing or renaming the
* temporary file by calling `close_tempfile_gently()`, and later call
* `delete_tempfile()` or `rename_tempfile()`.
*
* After the temporary file is renamed or deleted, the `tempfile`
* object is no longer valid and should not be reused.
*
* If the program exits before `rename_tempfile()` or
* `delete_tempfile()` is called, an `atexit(3)` handler will close
* and remove the temporary file.
*
* If you need to close the file descriptor yourself, do so by calling
* `close_tempfile_gently()`. You should never call `close(2)` or `fclose(3)`
* yourself, otherwise the `struct tempfile` structure would still
* think that the file descriptor needs to be closed, and a later
* cleanup would result in duplicate calls to `close(2)`. Worse yet,
* if you close and then later open another file descriptor for a
* completely different purpose, then the unrelated file descriptor
* might get closed.
*
*
* Error handling
* --------------
*
* `create_tempfile()` returns an allocated tempfile on success or NULL
* on failure. On errors, `errno` describes the reason for failure.
*
* `rename_tempfile()` and `close_tempfile_gently()` return 0 on success.
* On failure they set `errno` appropriately and return -1.
* `delete_tempfile()` and `rename` (but not `close`) do their best to
* delete the temporary file before returning.
*/
struct tempfile {
volatile struct volatile_list_head list;
volatile int fd;
FILE *volatile fp;
volatile pid_t owner;
struct strbuf filename;
char *directory;
};
/*
* Attempt to create a temporary file at the specified `path`. Return
* a tempfile (whose "fd" member can be used for writing to it), or
* NULL on error. It is an error if a file already exists at that path.
* Note that `mode` will be further modified by the umask, and possibly
* `core.sharedRepository`, so it is not guaranteed to have the given
* mode.
*/
struct tempfile *create_tempfile_mode(const char *path, int mode);
static inline struct tempfile *create_tempfile(const char *path)
{
return create_tempfile_mode(path, 0666);
}
/*
* Register an existing file as a tempfile, meaning that it will be
* deleted when the program exits. The tempfile is considered closed,
* but it can be worked with like any other closed tempfile (for
* example, it can be opened using reopen_tempfile()).
*/
struct tempfile *register_tempfile(const char *path);
/*
* mks_tempfile functions
*
* The following functions attempt to create and open temporary files
* with names derived automatically from a template, in the manner of
* mkstemps(), and arrange for them to be deleted if the program ends
* before they are deleted explicitly. There is a whole family of such
* functions, named according to the following pattern:
*
* x?mks_tempfile_t?s?m?()
*
* The optional letters have the following meanings:
*
* x - die if the temporary file cannot be created.
*
* t - create the temporary file under $TMPDIR (as opposed to
* relative to the current directory). When these variants are
* used, template should be the pattern for the filename alone,
* without a path.
*
* s - template includes a suffix that is suffixlen characters long.
*
* m - the temporary file should be created with the specified mode
* (otherwise, the mode is set to 0600).
*
* None of these functions modify template. If the caller wants to
* know the (absolute) path of the file that was created, it can be
* read from tempfile->filename.
*
* On success, the functions return a tempfile whose "fd" member is open
* for writing the temporary file. On errors, they return NULL and set
* errno appropriately (except for the "x" variants, which die() on
* errors).
*/
/* See "mks_tempfile functions" above. */
struct tempfile *mks_tempfile_sm(const char *filename_template,
int suffixlen, int mode);
/* See "mks_tempfile functions" above. */
static inline struct tempfile *mks_tempfile_s(const char *filename_template,
int suffixlen)
{
return mks_tempfile_sm(filename_template, suffixlen, 0600);
}
/* See "mks_tempfile functions" above. */
static inline struct tempfile *mks_tempfile_m(const char *filename_template, int mode)
{
return mks_tempfile_sm(filename_template, 0, mode);
}
/* See "mks_tempfile functions" above. */
static inline struct tempfile *mks_tempfile(const char *filename_template)
{
return mks_tempfile_sm(filename_template, 0, 0600);
}
/* See "mks_tempfile functions" above. */
struct tempfile *mks_tempfile_tsm(const char *filename_template,
int suffixlen, int mode);
/* See "mks_tempfile functions" above. */
static inline struct tempfile *mks_tempfile_ts(const char *filename_template,
int suffixlen)
{
return mks_tempfile_tsm(filename_template, suffixlen, 0600);
}
/* See "mks_tempfile functions" above. */
static inline struct tempfile *mks_tempfile_tm(const char *filename_template, int mode)
{
return mks_tempfile_tsm(filename_template, 0, mode);
}
/* See "mks_tempfile functions" above. */
static inline struct tempfile *mks_tempfile_t(const char *filename_template)
{
return mks_tempfile_tsm(filename_template, 0, 0600);
}
/* See "mks_tempfile functions" above. */
struct tempfile *xmks_tempfile_m(const char *filename_template, int mode);
/* See "mks_tempfile functions" above. */
static inline struct tempfile *xmks_tempfile(const char *filename_template)
{
return xmks_tempfile_m(filename_template, 0600);
}
/*
* Attempt to create a temporary directory in $TMPDIR and to create and
* open a file in that new directory. Derive the directory name from the
* template in the manner of mkdtemp(). Arrange for directory and file
* to be deleted if the program exits before they are deleted
* explicitly. On success return a tempfile whose "filename" member
* contains the full path of the file and its "fd" member is open for
* writing the file. On error return NULL and set errno appropriately.
*/
struct tempfile *mks_tempfile_dt(const char *directory_template,
const char *filename);
/*
* Associate a stdio stream with the temporary file (which must still
* be open). Return `NULL` (*without* deleting the file) on error. The
* stream is closed automatically when `close_tempfile_gently()` is called or
* when the file is deleted or renamed.
*/
FILE *fdopen_tempfile(struct tempfile *tempfile, const char *mode);
static inline int is_tempfile_active(struct tempfile *tempfile)
{
return !!tempfile;
}
/*
* Return the path of the lockfile. The return value is a pointer to a
* field within the lock_file object and should not be freed.
*/
const char *get_tempfile_path(struct tempfile *tempfile);
int get_tempfile_fd(struct tempfile *tempfile);
FILE *get_tempfile_fp(struct tempfile *tempfile);
/*
* If the temporary file is still open, close it (and the file pointer
* too, if it has been opened using `fdopen_tempfile()`) without
* deleting the file. Return 0 upon success. On failure to `close(2)`,
* return a negative value. Usually `delete_tempfile()` or `rename_tempfile()`
* should eventually be called regardless of whether `close_tempfile_gently()`
* succeeds.
*/
int close_tempfile_gently(struct tempfile *tempfile);
/*
* Re-open a temporary file that has been closed using
* `close_tempfile_gently()` but not yet deleted or renamed. This can be used
* to implement a sequence of operations like the following:
*
* * Create temporary file.
*
* * Write new contents to file, then `close_tempfile_gently()` to cause the
* contents to be written to disk.
*
* * Pass the name of the temporary file to another program to allow
* it (and nobody else) to inspect or even modify the file's
* contents.
*
* * `reopen_tempfile()` to reopen the temporary file, truncating the existing
* contents. Write out the new contents.
*
* * `rename_tempfile()` to move the file to its permanent location.
*/
int reopen_tempfile(struct tempfile *tempfile);
/*
* Close the file descriptor and/or file pointer and remove the
* temporary file associated with `tempfile`. It is a NOOP to call
* `delete_tempfile()` for a `tempfile` object that has already been
* deleted or renamed.
*/
void delete_tempfile(struct tempfile **tempfile_p);
/*
* Close the file descriptor and/or file pointer if they are still
* open, and atomically rename the temporary file to `path`. `path`
* must be on the same filesystem as the lock file. Return 0 on
* success. On failure, delete the temporary file and return -1, with
* `errno` set to the value from the failing call to `close(2)` or
* `rename(2)`. It is a bug to call `rename_tempfile()` for a
* `tempfile` object that is not currently active.
*/
int rename_tempfile(struct tempfile **tempfile_p, const char *path);
#endif /* TEMPFILE_H */
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...