Re: [PATCH] lockfile: fix buffer overflow in path handling

2013-07-07 Thread Junio C Hamano
Michael Haggerty writes: >> But either way, the fix looks good to me. > > Yes, the constant is an improvement and Peff's version is also fine with me. OK, will squash in. Thanks both. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.ke

Re: [PATCH] lockfile: fix buffer overflow in path handling

2013-07-07 Thread Michael Haggerty
On 07/07/2013 06:12 AM, Jeff King wrote: > On Sat, Jul 06, 2013 at 09:48:52PM +0200, Michael Haggerty wrote: > >> 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 LO

Re: [PATCH] lockfile: fix buffer overflow in path handling

2013-07-06 Thread Jeff King
On Sat, Jul 06, 2013 at 09:48:52PM +0200, Michael Haggerty wrote: > 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()

[PATCH] lockfile: fix buffer overflow in path handling

2013-07-06 Thread Michael Haggerty
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 locke