Skip to content

System.Console: allow terminfo files to be larger than 4KiB. #82038

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

Merged
merged 2 commits into from
Feb 14, 2023

Conversation

tmds
Copy link
Member

@tmds tmds commented Feb 13, 2023

Fixes #82026.

@adamsitnik @dotnet/area-system-console ptal.

@ghost ghost added area-System.Console community-contribution Indicates that the PR has been added by a community member labels Feb 13, 2023
@ghost
Copy link

ghost commented Feb 13, 2023

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #82026.

@adamsitnik @dotnet/area-system-console ptal.

Author: tmds
Assignees: -
Labels:

area-System.Console

Milestone: -

@@ -119,7 +119,9 @@ private static bool TryOpen(string filePath, [NotNullWhen(true)] out SafeFileHan
{
// Read in all of the terminfo data
long termInfoLength = RandomAccess.GetLength(fd);
const int MaxTermInfoLength = 4096; // according to the term and tic man pages, 4096 is the terminfo file size max
// according to the term and tic man pages, 4096 is the terminfo file size max
// Fedora includes terminfo files that are slightly larger than 4096.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the limit mentioned in the man pages is the maximum size of a compiled entry, and not an upper limit for the entire file. This code is then setting an artificial boundary.
We hadn't hit it before, so probably we're not likely to hit it again soon when we double it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember why I did it like this 8 years ago or whatever it was. Is there any reason to have a hard limit at all, rather than just reading/storing until EOF and growing along the way?

Copy link
Member Author

@tmds tmds Feb 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, these files are read from 'secure' locations (system or envvar-controlled).
My preference is to remove the limit check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this limit was added for "safety", not only is the location trusted as you say, but also is there anything stopping the file growing between the length check and reading it? Or on Unix does opening a fd (with O_RDONLY as here or otherwise) somehow give you a snapshot view?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there were a safety aspect, it'd be more about avoiding OOMs by unbounded memory growth. But I don't think it's an issue. We should just read the full file, regardless of length.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, there's no safety aspect, I just wanted to validate my assumption that there's no way with open() to somehow freeze the size of the file in a totally reliable way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on our discussion, I've removed the file size check.

Copy link
Member

@adamsitnik adamsitnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you @tmds!

@adamsitnik adamsitnik merged commit 54972b7 into dotnet:main Feb 14, 2023
@adamsitnik
Copy link
Member

/backport to release/7.0

@adamsitnik
Copy link
Member

/backport to release/6.0

@github-actions
Copy link
Contributor

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4172292157

@github-actions
Copy link
Contributor

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/4172293041

@github-actions
Copy link
Contributor

@adamsitnik backporting to release/6.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: System.Console: allow terminfo files to be larger than 4KiB.
Using index info to reconstruct a base tree...
A	src/libraries/System.Console/src/System/TermInfo.DatabaseFactory.cs
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): src/libraries/System.Console/src/System/TermInfo.DatabaseFactory.cs deleted in HEAD and modified in System.Console: allow terminfo files to be larger than 4KiB.. Version System.Console: allow terminfo files to be larger than 4KiB. of src/libraries/System.Console/src/System/TermInfo.DatabaseFactory.cs left in tree.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 System.Console: allow terminfo files to be larger than 4KiB.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions
Copy link
Contributor

@adamsitnik an error occurred while backporting to release/6.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

adamsitnik pushed a commit to adamsitnik/runtime that referenced this pull request Feb 21, 2023
# Conflicts:
#	src/libraries/System.Console/src/System/TermInfo.DatabaseFactory.cs
carlossanlop pushed a commit that referenced this pull request Mar 8, 2023
# Conflicts:
#	src/libraries/System.Console/src/System/TermInfo.DatabaseFactory.cs

Co-authored-by: Tom Deseyn <tom.deseyn@gmail.com>
@ghost ghost locked as resolved and limited conversation to collaborators Mar 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Console community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VerifyInstalledTermInfosParse fails for (upcoming) Fedora 38
4 participants