summaryrefslogtreecommitdiff
path: root/t/t9115
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2012-01-09 23:44:30 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-01-10 10:10:36 -0800
commit1eb10f4091931d6b89ff10edad63ce9c01ed17fd (patch)
tree6b15f865e2ab04d87c57842f341f7b7d8ec5f00d /t/t9115
parentcredentials: unable to connect to cache daemon (diff)
downloadtgif-1eb10f4091931d6b89ff10edad63ce9c01ed17fd.tar.xz
unix-socket: handle long socket pathnames
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t9115')
0 files changed, 0 insertions, 0 deletions