[PATCH 7 of 7] chg: raise the length limit of socket path

[Yuya Nishihara]

On Mon, 4 Apr 2016 16:14:05 +0100, Jun Wu wrote:
> On 04/04/2016 02:35 PM, Yuya Nishihara wrote:
> > Somewhat related: perhaps, we should keep sockdir and file names
> > separately,  
> 
> The issue is if chdir errors with EPERM as Simon said, we may want to fallback
> to full path. It's even better if we try the parent dir recursively until we
> hit the root dir.
> 
> > and make the "validate" command return only file names. That will reduce a
> > possible bug of accessing unsafe socket.  
> 
> Same issue but if we do this and enforce that the user must give a directory
> that has +x, things will be much easier to handle and safer. We can just keep a 
> dirfd and throw away the dir string.

Simon's comment is interesting, but I don't see benefit to allow u-x on the
socket dir. The socket dir shouldn't be world-accessible, and not be world-
movable (to prevent local attack), but there should be no reason to hide it
from the owner.

> I prefer this way (parse CHGSOCKNAME and save a dirfd during startup and we
> then forget about directory strings). cc Simon for opinions.
> 
> > I'm okay to drop CHGSOCKNAME and add CHGSOCKDIR instead, though it would
> > mean chg can no longer be a client for plain unix command server.  
> 
> This is not necessary since we can always parse CHGSOCKNAME to get CHGSOCKDIR
> during startup.

I meant CHGSOCKDIR would make more sense because we have more than one sockets
and a lock file in it.