Terry Wilson <[email protected]> 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?
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
