New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib/9pfs: Return ENOTSUP on ioctl requests except for FIONBIO #1098
lib/9pfs: Return ENOTSUP on ioctl requests except for FIONBIO #1098
Conversation
efd0e7e
to
e068e51
Compare
Currently `9pfs` returns 0 for any `ioctl` request (except for `TIOCGWINSZ`), which leads to multiple cases of files being interpreted as terminals. You can see this problem when running python scripts, since python uses `ioctl` calls to check if it should open up the interactive interpretor or execute a script. Same thing could happen for other applications that rely on `ioctl` operations being properly executed, so the best way to go would be return `ENOTSUP` (as is used to happen before commit 28d0edf). If the `ioctl` call always return `ENOTSUP`, the Ruby binary compatibility application will fail, since it tries to set O_ASYNC and breaks on error, even if it does not directly depends on that, so for now add a special case for that. Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com>
fb43a70
to
524d0fb
Compare
524d0fb
to
dc15c69
Compare
Thanks, @StefanJum . This looks OK to me. I'm waiting for the final review, accept from @skuenzer and then I'll add my review tag. |
dc15c69
to
0725c8e
Compare
0725c8e
to
34b4f9e
Compare
34b4f9e
to
19eb928
Compare
19eb928
to
f5a8dcc
Compare
@StefanJum , @mogasergiu , this looks fine with me. I'll wait for @skuenzer's confirmation that this is OK and then I'll add my reviewer tag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also mention the fact that you introduced the new IOCTL macro's in the commit message. But other than that, LGTM! 👍
Reviewed-by: Sergiu Moga sergiu@unikraft.io
f5a8dcc
to
4b78fd0
Compare
Added the macro description in the commit message. |
4b78fd0
to
a70f09d
Compare
Some applications (e.g. python) will use `ioctl()` calls to check if an interactive interpretor should be started or if a file should be read. `9pfs` should respond to all terminal-related calls with an `ENOTTY` error, so applications know that they are not running in an interactive environment. In order to detect the ioctl request type, add a new macro, `IOCTL_CMD_ISTYPE(cmd, type)`, which will check the corresponding bytes from the request number (an enhanced version of the Linux `_IOC_TYPE`). Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com>
a70f09d
to
b9f90d0
Compare
#define IOCTL_CMD_ISTYPE(cmd, type) \ | ||
((cmd & (IOCTL_CMD_TYPE_MASK)) == \ | ||
(((type) << IOCTL_CMD_TYPE_SHIFT) & \ | ||
IOCTL_CMD_TYPE_MASK)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bellísimo 💅👌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work.
Approved-by: Simon Kuenzer simon@unikraft.io
Currently `9pfs` returns 0 for any `ioctl` request (except for `TIOCGWINSZ`), which leads to multiple cases of files being interpreted as terminals. You can see this problem when running python scripts, since python uses `ioctl` calls to check if it should open up the interactive interpretor or execute a script. Same thing could happen for other applications that rely on `ioctl` operations being properly executed, so the best way to go would be return `ENOTSUP` (as is used to happen before commit 28d0edf). If the `ioctl` call always return `ENOTSUP`, the Ruby binary compatibility application will fail, since it tries to set O_ASYNC and breaks on error, even if it does not directly depends on that, so for now add a special case for that. Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com> Reviewed-by: Sergiu Moga <sergiu@unikraft.io> Approved-by: Simon Kuenzer <simon@unikraft.io> GitHub-Closes: #1098
Some applications (e.g. python) will use `ioctl()` calls to check if an interactive interpretor should be started or if a file should be read. `9pfs` should respond to all terminal-related calls with an `ENOTTY` error, so applications know that they are not running in an interactive environment. In order to detect the ioctl request type, add a new macro, `IOCTL_CMD_ISTYPE(cmd, type)`, which will check the corresponding bytes from the request number (an enhanced version of the Linux `_IOC_TYPE`). Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com> Reviewed-by: Sergiu Moga <sergiu@unikraft.io> Approved-by: Simon Kuenzer <simon@unikraft.io> GitHub-Closes: #1098
Currently `9pfs` returns 0 for any `ioctl` request (except for `TIOCGWINSZ`), which leads to multiple cases of files being interpreted as terminals. You can see this problem when running python scripts, since python uses `ioctl` calls to check if it should open up the interactive interpretor or execute a script. Same thing could happen for other applications that rely on `ioctl` operations being properly executed, so the best way to go would be return `ENOTSUP` (as is used to happen before commit 28d0edf). If the `ioctl` call always return `ENOTSUP`, the Ruby binary compatibility application will fail, since it tries to set O_ASYNC and breaks on error, even if it does not directly depends on that, so for now add a special case for that. Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com> Reviewed-by: Sergiu Moga <sergiu@unikraft.io> Approved-by: Simon Kuenzer <simon@unikraft.io> GitHub-Closes: #1098
Some applications (e.g. python) will use `ioctl()` calls to check if an interactive interpretor should be started or if a file should be read. `9pfs` should respond to all terminal-related calls with an `ENOTTY` error, so applications know that they are not running in an interactive environment. In order to detect the ioctl request type, add a new macro, `IOCTL_CMD_ISTYPE(cmd, type)`, which will check the corresponding bytes from the request number (an enhanced version of the Linux `_IOC_TYPE`). Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com> Reviewed-by: Sergiu Moga <sergiu@unikraft.io> Approved-by: Simon Kuenzer <simon@unikraft.io> GitHub-Closes: #1098
Currently ramfs returns EINVAL for any ioctl request, which leads to the Ruby binary compatibility application to fail, since it tries to set `O_ASYNC` and breaks on error, even if it does not directly depends on it being set. Add a special case to treat `O_ASYNC`, return `ENOTSUP` by default, and return `ENOTTY` on every `ioctl()` call related to a terminal. The implementation is similar to what we currently have in `lib/9pfs/`, introduced by unikraft/unikraft#1098 GitHub-Fixes: unikraft#1186 Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com>
Currently ramfs returns EINVAL for any ioctl request, which leads to the Ruby binary compatibility application to fail, since it tries to set `O_ASYNC` and breaks on error, even if it does not directly depends on it being set. Add a special case to treat `O_ASYNC`, return `ENOTSUP` by default, and return `ENOTTY` on every `ioctl()` call related to a terminal. The implementation is similar to what we currently have in `lib/9pfs/`, introduced by unikraft#1098 GitHub-Fixes: unikraft#1186 Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com>
Currently ramfs returns EINVAL for any ioctl request, which leads to the Ruby binary compatibility application to fail, since it tries to set `O_ASYNC` and breaks on error, even if it does not directly depends on it being set. Add a special case to treat `O_ASYNC`, return `ENOTSUP` by default, and return `ENOTTY` on every `ioctl()` call related to a terminal. The implementation is similar to what we currently have in `lib/9pfs/`, introduced by #1098 GitHub-Fixes: #1186 Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com>
Currently ramfs returns EINVAL for any ioctl request, which leads to the Ruby binary compatibility application to fail, since it tries to set `O_ASYNC` and breaks on error, even if it does not directly depends on it being set. Add a special case to treat `O_ASYNC`, return `ENOTSUP` by default, and return `ENOTTY` on every `ioctl()` call related to a terminal. The implementation is similar to what we currently have in `lib/9pfs/`, introduced by #1098 Signed-off-by: Stefan Jumarea <stefanjumarea02@gmail.com> Reviewed-by: Razvan Deaconescu <razvand@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> GitHub-Fixes: #1186 GitHub-Closes: #1202
Currently
9pfs
returns 0 for anyioctl
request (except forTIOCGWINSZ
), which leads to multiple cases of files being interpreted as terminals. You can see this problem when running python scripts, since python usesioctl
calls to check if it should open up the interactive interpretor or execute a script.Same thing could happen for other applications that rely on
ioctl
operations being properly executed, so the best way to go would be returnEINVAL
(as is used to happen before commit 28d0edf).If the
ioctl
call always returnEINVAL
, the Ruby binary compatibility application will fail, since it tries to set O_ASYNC and breaks on error, even if it does not directly depends on that, so for now add a special case for that.So as an overview:
staging
branch) -> binary compatibilitypython3
scripts (usingglibc
as the libc, since themusl
case is covered by theTIOCGWINSZ
special case) fails, since it thinks it runs inside a terminal.The same could happen for any application that expects the
ioctl
request to be properly handeled.ruby
works in binary compatibility mode.ioctl
always returnsEINVAL
(as it should, since we do not handle theioctl
requests) ->python3
scripts work fine,ruby
fails in binary compatibility mode, since it tries to setO_ASYNC
(even if it works fine without it).python3
andruby
work fine, nothing else seems to currently break, even if adding the special case forFIONBIO
is very hackish.Prerequisite checklist
checkpatch.uk
on your commit series before opening this PR;Base target
python3
bincompat,ruby
bincompat