On Mon, Jun 13, 2016 at 05:36:34PM -0400, Aaron Conole wrote:
> > If these limitations are unacceptable, I can see how we can use
> > chmod. After all, as you point out, it's probably better to do it
> > in OVS than in some script.
>
> I think fchmod and fchown may actually be the correct calls to have, and
> will refactor these chown/chmod utils functions as such, which (I
> believe) avoids the race as you describe.
There are some pitfalls with fchmod() on Unix domain sockets, especially
on non-Linux systems. Please refer to bind_unix_socket() in
lib/socket-util-unix.c:
/* Binds Unix domain socket 'fd' to a file with permissions 0700. */
static int bind_unix_socket(int fd, struct sockaddr *sun, socklen_t sun_len)
{
const mode_t mode = 0770; /* Allow both user and group access. */
if (LINUX) {
/* On Linux, the fd's permissions become the file's permissions.
* fchmod() does not affect other files, like umask() does. */
if (fchmod(fd, mode)) {
return errno;
}
/* Must be after fchmod(). */
if (bind(fd, sun, sun_len)) {
return errno;
}
return 0;
} else {
/* On FreeBSD and NetBSD, only the umask affects permissions. The
* umask is process-wide rather than thread-specific, so we have to use
* a subprocess for safety. */
pid_t pid = fork();
if (!pid) {
umask(mode ^ 0777);
_exit(bind(fd, sun, sun_len) ? errno : 0);
} else if (pid > 0) {
int status;
int error;
do {
error = waitpid(pid, &status, 0) < 0 ? errno : 0;
} while (error == EINTR);
return (error ? error
: WIFEXITED(status) ? WEXITSTATUS(status)
: WIFSIGNALED(status) ? EINTR
: ECHILD /* WTF? */);
} else {
return errno;
}
}
}
I do not know whether the same pitfalls apply to fchown().
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
