path: root/unix-socket.c
AgeCommit message (Collapse)Author
2014-09-02Merge branch 'rs/strbuf-getcwd'Junio C Hamano
Reduce the use of fixed sized buffer passed to getcwd() calls by introducing xgetcwd() helper. * rs/strbuf-getcwd: use strbuf_add_absolute_path() to add absolute paths abspath: convert absolute_path() to strbuf use xgetcwd() to set $GIT_DIR use xgetcwd() to get the current directory or die wrapper: add xgetcwd() abspath: convert real_path_internal() to strbuf abspath: use strbuf_getcwd() to remember original working directory setup: convert setup_git_directory_gently_1 et al. to strbuf unix-sockets: use strbuf_getcwd() strbuf: add strbuf_getcwd()
2014-07-28unix-sockets: use strbuf_getcwd()René Scharfe
Instead of using a PATH_MAX-sized buffer, which can be too small on some file systems, use strbuf_getcwd(), which handles any path getcwd() returns. Also preserve the errno set by strbuf_getcwd() instead of setting it to ENAMETOOLONG; that way a more appropriate error message can be shown based on the actual reason for failing. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2014-07-21unix-socket: remove stale socket before calling chdir()René Scharfe
unix_stream_listen() is given a path. It calls unix_sockaddr_init(), which in turn can call chdir(). After that a relative path doesn't mean the same as before. Any use of the original path should thus happen before that call. For that reason, unlink the given path (to get rid of a possibly existing stale socket) right at the beginning of the function. Noticed-by: Karsten Blees <> Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2012-01-12unix-socket: do not let close() or chdir() clobber errno during cleanupJonathan Nieder
unix_stream_connect and unix_stream_listen return -1 on error, with errno set by the failing underlying call to allow the caller to write a useful diagnosis. Unfortunately the error path involves a few system calls itself, such as close(), that can themselves touch errno. This is not as worrisome as it might sound. If close() fails, this just means substituting one meaningful error message for another, which is perfectly fine. However, when the call _succeeds_, it is allowed to (and sometimes might) clobber errno along the way with some undefined value, so it is good higiene to save errno and restore it immediately before returning to the caller. Do so. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2012-01-10unix-socket: handle long socket pathnamesJeff King
On many systems, the sockaddr_un.sun_path field is quite small. Even on Linux, it is only 108 characters. A user of the credential-cache daemon can easily surpass this, especially if their home directory is in a deep directory tree (since the default location expands ~/.git-credentials). We can hack around this in the unix-socket.[ch] code by doing a chdir() to the enclosing directory, feeding the relative basename to the socket functions, and then restoring the working directory. This introduces several new possible error cases for creating a socket, including an irrecoverable one in the case that we can't restore the working directory. In the case of the credential-cache code, we could perhaps get away with simply chdir()-ing to the socket directory and never coming back. However, I'd rather do it at the lower level for a few reasons: 1. It keeps the hackery behind an opaque interface instead of polluting the main program logic. 2. A hack in credential-cache won't help any unix-socket users who come along later. 3. The chdir trickery isn't that likely to fail (basically it's only a problem if your cwd is missing or goes away while you're running). And because we only enable the hack when we get a too-long name, it can only fail in cases that would have failed under the previous code anyway. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-12-12credentials: add "cache" helperJeff King
If you access repositories over smart-http using http authentication, then it can be annoying to have git ask you for your password repeatedly. We cache credentials in memory, of course, but git is composed of many small programs. Having to input your password for each one can be frustrating. This patch introduces a credential helper that will cache passwords in memory for a short period of time. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>