Fix server startup on NetBSD (and probably other systems) #838
Conversation
my_open_parent_dir_nosymlinks() calls openat() with dfd = -1, which Linux takes for root of filesystem, but this behavior is not standard as per OpenGroup XSH: http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html On NetBSD, dfd = -1 causes openat() to fail with EBADF, which breaks server startup. The same result probaly happens on any non Linux system implementing openat(). The proposed fix is to call plain open() when dfd = -1
From upstream MariaDB/server#838
| if (dfd == -1) | ||
| fd = open(s, O_NOFOLLOW | O_PATH | O_CLOEXEC); | ||
| else | ||
| #endif |
There was a problem hiding this comment.
I'd suggest to move it before the loop and instead do something like:
#ifndef linux
dfd= open("/", O_NOFOLLOW | O_PATH | O_CLOEXEC);
#endif
|
Strictly speaking, Linux does not take
The OpenGroup page you mentioned says
As far as I understand, it means that if the path is "/", dfd does not matter and could as well be -1. |
|
On Tue, Jan 29, 2019 at 09:18:30AM +0000, Sergei Golubchik wrote:
If NetBSD behaves differently, it must be a NetBSD bug.
Well, then we will fix NetBSD, but if you want to support
relased NetBSD so far, the workaround is required.
…--
Emmanuel Dreyfus
manu@netbsd.org
|
|
Yes, I tend to agree with that |
Opengroup says "The openat() function shall be equivalent to the open() function except in the case where path specifies a relative path", but says nothing about fdat usage when path is absolute; https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html We used to always reslove fdat, leading to error if it was invalid (e.g.: -1). That caused portability problem with other systems that just ignore it. See discussion in a pull request to work around that problem with MariaDB: MariaDB/server#838 We fix the problem by ignoring fdat when path is absolute.
Opengroup says "The openat() function shall be equivalent to the open() function except in the case where path specifies a relative path", but says nothing about fdat usage when path is absolute; https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html We used to always reslove fdat, leading to error if it was invalid (e.g.: -1). That caused portability problem with other systems that just ignore it. See discussion in a pull request to work around that problem with MariaDB: MariaDB/server#838 We fix the problem by ignoring fdat when path is absolute.
Opengroup says "The openat() function shall be equivalent to the open() function except in the case where path specifies a relative path", but says nothing about fdat usage when path is absolute; https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html We used to always reslove fdat, leading to error if it was invalid (e.g.: -1). That caused portability problem with other systems that just ignore it. See discussion in a pull request to work around that problem with MariaDB: MariaDB/server#838 We fix the problem by ignoring fdat when path is absolute.
|
Emmanuel Dreyfus seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
grooverdan
added
the
need feedback
|
Hello @manu0401, I'm trying to go through older pull requests so that we can work towards getting them moving again. Is this patch still something you would like to see in MariaDB? If so I can try to assist you in getting it to a place where it can be merged. Please let me know how you would like to proceed. |
|
Hello @manu0401, I'm going to close this one for now as we have not heard from you. But please feel free to reopen or contact me if you wish to continue this one or discuss it further. |
my_open_parent_dir_nosymlinks() calls openat() with dfd = -1, which
Linux takes for root of filesystem, but this behavior is not standard
as per OpenGroup XSH:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
On NetBSD, dfd = -1 causes openat() to fail with EBADF, which breaks
server startup. The same result probaly happens on any non Linux
system implementing openat().
The proposed fix is to call plain open() when dfd = -1