[ovs-dev] [PATCH] Fix socket permissions on Linux

Ben Pfaff blp at ovn.org
Mon Aug 20 16:29:48 UTC 2018


On Mon, Aug 20, 2018 at 11:08:36AM -0400, Aaron Conole wrote:
> Terry Wilson <twilson at redhat.com> writes:
> 
> >> Gather 'round folks, and let me tell you the tale of a series long
> >> ago posted:
> >>
> >> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321866.html
> >>
> >> Something... something ... black magic...
> >> I think the fchmod needs to happen after the bind for the permissions
> >> to actually be changed.  That's how the unit tests in that series are
> >> coded.
> >
> > If you move fchmod after the bind, you get 0755 and not 0750 on my
> > system. It seems weird fchmod interacting with umask since it seems
> > like the whole purpose of chmod/fchmod are to change permissions
> > ignoring umask. You certainly aren't going to get the same behavior
> > with fchmod on a regular file anyway. It seemed like the patch that
> > specifically changed 0700 -> 0770 intended group permissions to always
> > be there. I can see arguments both ways, though. The problem with
> > modifying umask before calling is that you are changing the
> > permissions for every created file (log files, etc.). Maybe that isn't
> > a problem, I just know that it was something that came up in our
> > internal discussions hacking around things with umask.
> 
> Strange.  I've tested on regular files, and find that umask is *correctly*
> ignored.  The test program I'm using:
> 
> --- 8< ---
> #include <fcntl.h>
> #include <stdio.h>
> #include <sys/stat.h>
> #include <unistd.h>
> 
> int main(int argc, char *argv[])
> {
>     /* Change the mode */
>     if (argc < 2) {
>         printf("pass a filename\n");
>         return -1;
>     }
> 
>     int fd = open(argv[1], O_RDWR);
>     if (fd < 0) {
>         perror("open");
>         return -1;
>     }
> 
>     fchmod(fd, 0770);
>     close(fd);
>     return 0;
> }
> --- >8 ---
> 
> output
> -----------
> 
> 10:42:20 aconole /tmp$ umask
> 0022
> 10:42:22 aconole /tmp$ touch tmp.foo
> 10:42:25 aconole /tmp$ ls -lah | grep tmp.foo
> -rw-r--r--.  1 aconole aconole    0 Aug 20 10:42 tmp.foo
> 10:42:29 aconole /tmp$ ./test tmp.foo
> 10:42:36 aconole /tmp$ ls -lah | grep tmp.foo
> -rwxrwx---.  1 aconole aconole    0 Aug 20 10:42 tmp.foo
> 
> -----------
> 
> of course, /tmp has some other sticky bits set, but I tried in my own
> home directory, with the same results.
> 
> Then, I played a bit with unix sockets.  What I found was interesting.
> 
> If I use fchmod on the actual socket, it seems not possible to adjust
> the permissions after creation time.  That means post bind, the
> permissions are locked for fd, at least as far as fchmod goes.
> 
> HOWEVER, if I independently call 'chmod(path, mode)' the mode bits are
> changed without factoring the umask (as I expect).  There might need to
> be some additional work to get this to do the right thing under linux,
> but I think it's possible without going through the clone path.  Looking
> at the old patches I had, I did a traversal and eventually fchmodat(),
> which probably does the right thing (but I haven't dusted those patches
> off to actually try them out).
> 
> Ben, Terry, how would you feel if I did some minor necromancy on that
> code?  Any objections?

If you can do something that avoids fork and path-traversal issues, that
would be great.


More information about the dev mailing list