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

[Simon Farnsworth]

On 04/04/2016 16:14, 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.
>
> I prefer this way (parse CHGSOCKNAME and save a dirfd during startup and we
> then forget about directory strings). cc Simon for opinions.
>

I want very clear error messages (with perror-like translation of errno) 
so that if it does go wrong, it's easy for the user to work out what 
they did and to fix it without coming to us for help.

Something like (pseudocode):

abortmsg("chg: cannot chdir: %s: %s (errno = %d)",
     dir,
     stringerror(errno),
     errno
);

in analogy to bash's:
-bash: cd: simonfar/: Permission denied

That way, the user can see that it's an external fault, and diagnose 
using shell commands.

In a perfect world, it'd also be possible to fall back to a straight 
connect() without the chdir(), but that's less of a concern for me.

>> 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.

-- 
Simon Farnsworth