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

Yuya Nishihara yuya at tcha.org
Tue Apr 5 12:29:35 EDT 2016


On Tue, 5 Apr 2016 16:07:21 +0100, Jun Wu wrote:
> On 04/05/2016 02:43 PM, Yuya Nishihara wrote:
> > I've initially added CHGSOCKNAME only for testing purpose, so it doesn't
> > ensure that the socket path is good. That is my fault.  
> 
> We can apply the directory check for CHGSOCKNAME as well. I will do that
> in the next dirfd patch. I personally want a way to skip the check though.
> 
> >> I feel what chgserver uses is a set of files with a common prefix
> >> (basename), instead of a directory. So two chg servers can use a same
> >> directory as long as they use different basenames. The default
> >> lockfilepath should probably be changed to "dir/basename.lock" from
> >> "dir/lock".  
> >
> > What's the benefit of it? I don't think users would care much how sockets
> > were managed.  
> 
> Flexibility. For advanced users and developers. For example, with
> skiphash=False, I may want to manually set
> CHGSOCKNAME=/tmp/chg1000/server-a576a2e8e8aa to test if redirect works or not.
>
> I also believe it's the user's responsibility to take care of the permissions,
> if they do not use our default setting and specify socket path themselves.
> And maybe they don't think other users are enemies and just want to let other
> users access their private socket sometimes?

As long as CHGSOCKNAME is a debug option, it should be fine. (and we need a
debug option, right?) So feel free to disregard my CHGSOCKDIR rant. Let's
revisit it later.

> That said, I will still add the check to notice them and make the check
> skip-able so we have good security in all common cases and maximum flexibility.

Separate user/debug options? such as CHGFORCESOCKNAME and CHGSOCKDIR.

> Other software with similar pattern do not enforce private directories either,
> for example, ssh ControlMaster and emacsclient.

Oh, then how could I write that code? I don't remember where I've copied that
concept from. ;)


More information about the Mercurial-devel mailing list