git/lockfile.c, branch v2.0.2

lockfile: fix buffer overflow in path handling

2013-07-07T17:29:28Z

The path of the file to be locked is held in lock_file::filename, which is a fixed-length buffer of length PATH_MAX. This buffer is also (temporarily) used to hold the path of the lock file, which is the path of the file being locked plus ".lock". Because of this, the path of the file being locked must be less than (PATH_MAX - 5) characters long (5 chars are needed for ".lock" and one character for the NUL terminator). On entry into lock_file(), the path length was only verified to be less than PATH_MAX characters, not less than (PATH_MAX - 5) characters. When and if resolve_symlink() is called, then that function is correctly told to treat the buffer as (PATH_MAX - 5) characters long. This part is correct. However: * If LOCK_NODEREF was specified, then resolve_symlink() is never called. * If resolve_symlink() is called but the path is not a symlink, then the length check is never applied. So it is possible for a path with length (PATH_MAX - 5 <= len < PATH_MAX) to make it through the checks. When ".lock" is strcat()ted to such a path, the lock_file::filename buffer is overflowed. Fix the problem by adding a check when entering lock_file() that the original path is less than (PATH_MAX - 5) characters. [jc: with independent development by Peff] Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Name make_*_path functions more accurately

2011-03-17T23:08:30Z

Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: Carlos Martín Nieto Signed-off-by: Junio C Hamano

lockfile: show absolute filename in unable_to_lock_message

2010-01-12T23:48:24Z

When calling a git command from a subdirectory and a file locking fails, the user will get a path relative to the root of the worktree, which is invalid from the place where the command is ran. Make it easy for the user to know which file it is. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

git branch -D: give a better error message when lockfile creation fails

2009-09-29T15:14:47Z

Previously the old error message just told the user that it was not possible to delete the ref from the packed-refs file. Give instructions on how to resolve the problem. Signed-off-by: Miklos Vajna Signed-off-by: Jeff King Signed-off-by: Shawn O. Pearce

Merge branch 'ar/unlink-err'

2009-05-18T16:01:06Z

* ar/unlink-err: print unlink(2) errno in copy_or_link_directory replace direct calls to unlink(2) with unlink_or_warn Introduce an unlink(2) wrapper which gives warning if unlink failed

Fix a bunch of pointer declarations (codestyle)

2009-05-01T22:17:31Z

Essentially; s/type* /type */ as per the coding guidelines. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

replace direct calls to unlink(2) with unlink_or_warn

2009-04-30T01:37:41Z

This helps to notice when something's going wrong, especially on systems which lock open files. I used the following criteria when selecting the code for replacement: - it was already printing a warning for the unlink failures - it is in a function which already printing something or is called from such a function - it is in a static function, returning void and the function is only called from a builtin main function (cmd_) - it is in a function which handles emergency exit (signal handlers) - it is in a function which is obvously cleaning up the lockfiles Signed-off-by: Alex Riesen Signed-off-by: Junio C Hamano

Make the 'lock file' exists error more informative

2009-03-05T04:35:19Z

It looks like someone did 90% of the work, then forgot to actually use the function in one place. Also the helper function did not use the correct variable. Signed-off-by: Junio C Hamano

Merge branch 'maint'

2009-02-20T07:44:07Z

* maint: More friendly message when locking the index fails. Document git blame --reverse. Documentation: Note file formats send-email accepts

More friendly message when locking the index fails.

2009-02-20T07:22:57Z

Just saying that index.lock exists doesn't tell the user _what_ to do to fix the problem. We should give an indication that it's normally safe to delete index.lock after making sure git isn't running here. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano