On Thu, Aug 16, 2018 at 10:38:01PM -0500, Terry Wilson wrote:
> >> It doesn't (and never has) on my Centos 7 machine. I ran into this a
> >> couple of years ago and ended up just working around it. As an example
> >> after make rpm-fedora and installing:
> >> [centos@test x86_64]$ ls -al /var/run/openvswitch/db.sock
> >> srwxr-x---.  1 openvswitch openvswitch    0 Aug 16 22:09 db.sock
> >>
> >> So we've got 0750 and not 0770 like the hardcoded value in the source.
> >
> > Presumably, that's 0770 modulo the umask, which is the same thing you
> > get out of the third argument to open().  I guess your umask is 0022.
> 
> Ok, so fchmod() followed by bind() is similar to 3-arg open(). That
> makes sense to me. Still a little confused about fchmod() after bind()
> not doing anything when chmod does and they both eventually call into
> chmod_common(), with fchmod() just grabbing the file path to pass in
> to chmod_common()

I get the impression that there are two different entities, which are
the socket and a file that references the socket.  The socket has a mode
that can be set with fchmod(), and bind() takes that mode and applies
the umask to it and uses that as the initial mode for the file that it
creates.  The socket's mode is otherwise ignored, so that you can
fchmod() the socket as much as you want afterward and there's no visible
behavioral change.  But chmod() gets to the file and changes its mode
and that's what actually influences behavior.

> > If we need exactly 0770 then it's harder and we probably have to
> 
> To me this seems very beneficial to have since setting umask before
> calling ovsdb-server means that log files etc. also get created with
> different permissions. In any case, the behavior is different between
> the Linux and *BSD implementations of bind_unix_socket() since Linux
> takes does mode&~umask and the*BSD version does umask = mode.
> 
> Thanks for the explanation so far, anyway. This is surprisingly confusing.

It's bizarre.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to