On Mon, Aug 20, 2018 at 11:08:36AM -0400, Aaron Conole wrote: > Terry Wilson <twil...@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. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev