diff options
author | Jeff King <peff@peff.net> | 2012-01-09 23:44:30 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2012-01-10 10:10:36 -0800 |
commit | 1eb10f4091931d6b89ff10edad63ce9c01ed17fd (patch) | |
tree | 6b15f865e2ab04d87c57842f341f7b7d8ec5f00d /t | |
parent | credentials: unable to connect to cache daemon (diff) | |
download | tgif-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')
0 files changed, 0 insertions, 0 deletions